Date: Fri, 23 Nov 2007 03:45:28 -0500 From: Stephan Uphoff <ups@freebsd.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, Max Laier <max@love2party.net>, freebsd-arch@freebsd.org Subject: Re: rwlocks, correctness over speed. Message-ID: <47469328.8020404@freebsd.org> In-Reply-To: <20071123082339.GN44563@elvis.mu.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > -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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47469328.8020404>