rwlocks, correctness over speed.

[Julian Elischer]

Julian Elischer wrote:
> 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.
> 
> recursion is hard for the caller to know because unrelated code could 
> have done the original calls.
> The only way it can know is if there is some generic recursion detection.

translation: make recursion as hard as possible, (or disallow)

> 
>>
>> -Alfred
>>
>> _______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"