Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Nov 2007 08:34:26 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        Attilio Rao <attilio@freebsd.org>, Max Laier <max@love2party.net>, Stephan Uphoff <ups@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: rwlocks, correctness over speed.
Message-ID:  <47470112.8090005@elischer.org>
In-Reply-To: <4746FC5B.3040809@elischer.org>
References:  <20071121222319.GX44563@elvis.mu.org>	<200711221641.02484.max@love2party.net>	<3bbf2fe10711220753u435ff4cbxa94d5b682292b970@mail.gmail.com>	<200711221726.27108.max@love2party.net>	<20071123082339.GN44563@elvis.mu.org> <4746FC5B.3040809@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
> Alfred Perlstein wrote:
>> * Max Laier <max@love2party.net> [071122 14:40] wrote:
>>> On Thursday 22 November 2007, Attilio Rao wrote:
>>>> 2007/11/22, Max Laier <max@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@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
> 
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47470112.8090005>