rwlocks, correctness over speed.

[Stephan Uphoff]

Alfred Perlstein wrote:
> * Max Laier <max at love2party.net> [071122 14:40] wrote:
>   
>> On Thursday 22 November 2007, 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...
>>>       
>> How about adding rwlock_try_rlock() which would do the following:
>>  1) Only variant to allow[1] read recursion and ...
>>  2) ... only if no outstanding write requests
>>  3) Let the caller deal with failure
>>
>> This can be implemented statically, so no overhead in the fast path.  The 
>> caller is in the best position to decide if it is recursing or not - 
>> could keep that info on the stack - and can either fail[2] or do a normal 
>> rwlock_rlock() which would wait for the writer to enter and exit.
>>
>> [2] In most situation where you use read locks you can fail or roll back 
>> carefully as you didn't change anything - obviously.  In pfil - for 
>> instance - we just dropped the packet if there was a writer waiting.
>>
>> [1] "allow" in terms of WITNESS - if that can be done.
>>     
>
> The problem is that there is no tracking in the common case (without
> additional overhead), so you can't know if you're recursing, unless
> you track it yourself.
>
> -Alfred
>
>
>   
I talked with Attilio about that on  IRC.
Most common cases of writer starvation (but not all) could be solved by 
keeping a per thread count of shared acquired rwlocks.
If a rwlock is currently locked as shared/read AND a thread is blocked 
on it to lock it exclusively/write - then new shared/read locks
will only be granted to thread that already has a shared lock. (per 
thread shared counter is non zero)

To be honest I am a bit twitchy about a lock without priority 
propagation - especially since in FreeBSD threads run with user priority 
in kernel
space and can get preempted.

Stephan