rwlocks, correctness over speed.
Alfred Perlstein
alfred at freebsd.org
Fri Nov 23 01:24:20 PST 2007
* Stephan Uphoff <ups at freebsd.org> [071123 00:46] 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.
> >
> >-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
That's an interesting hack, I guess it could be done.
I would still like to disallow recursion.
Can we come to a concensus on that?
--
- Alfred Perlstein
More information about the freebsd-arch
mailing list