rwlocks, correctness over speed.

[Stephan Uphoff]

Attilio Rao wrote:
> 2007/11/22, Max Laier <max at love2party.net>:
>   
>> rwlocks are already used in places that do recursive reads.  The one place
>> I'm certain about is pfil(9) and we need a proper sollution for this.
>> Before rwlocks were used, I had a handrolled locking that supported both
>> read/write semantics and starvation avoidance - at the cost of failing to
>> allow futher read access when a writer asked for access.  This however,
>> was quite application specific and not the most efficient implementation
>> either.
>>     
>
> I'm not a pfil(9) expert, but for what I've heard, rmlocks should be
> really good for it, shouldn't them?
>
> The concept is that if we want to maintain fast paths for rwlock we
> cannot do too much tricks there. And you can really deadlock if you
> allow recursion on readers...
>
>   
>> If we were to disallow read recursion, we should have some generic lock
>> type that does allow it.  rmlock(9)s seem to support full priority
>> propagation even for recursed readers.  Can they be MFCed so that we have
>> an alternative?  Are they considered ready for production?  Should we
>> switch pfil(9) to them?  It seems like a perfect match.
>>     
>
> I've not looked over rmlocks so much, but as they track readers they
> can do priority propagation (if it is not implemented, it could be
> done -- not sure about the cost of the operation though).
>   
Yes - rmlock does priority propagation to readers.
(One reader at a time until no more readers are left)

> Attilio
>
>
>