Re: rwlocks, correctness over speed.

* Robert Watson <rwatson@xxxxxxxxxxx> [071123 16:27] wrote:

On Fri, 23 Nov 2007, Stephan Uphoff wrote:

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.

That's an interesting hack, I guess it could be done.

I would still like to disallow recursion.

Oh - I am all for disallowing recursion. In my opinion the only valid
place for a thread to acquire the same lock multiple times is inside a
transaction system with full deadlock detection. The question is if we can
do that this late in the game? Maybe we could make non recursive the
default and add a call rw_allow_recurse or rw_init_recurse to allow
recursion on a lock if we can't get away with the straight out removal of
the option? (Or less desirable - keep the current default and add
functions to disallow recursion)

While I'm no great fan of recursion, the reality is that many of our kernel
subsystems are not yet ready to disallow recursion on locks. Take a look
at the cases where we explicitly enable recursive acquisition for
mutexes--in practice, most network stack mutexes are recursive due to the
recursive calling in the network stack. While someday I'd like to think
we'll be able to eliminate some of that, but it won't be soon since it
requires significant reworking of very complicated code. The current model
in which recursion is explicitly enabled only where still required seems to
work pretty well for the existing code, although it's hard to say yet in
the code I've looked at whether read recursion would be required--the
situations I have in mind would require purely write recursion. There's
one case in the UNIX domain socket code where we do a locked test and
conditional lock/unlock with an rwlock for exclusive locking because
recursion isn't currently supported, and that's not a usage I'd like to
encourage more of.

Yes that's all well and good, however we have to come to a consensus
on whether to bite the bullet and implement recursion tracking on
rwlocks or disallow it, because unless we do this, we open the system
up to starvation live-lock.

So let's make a decision about it instead of just talking about it.

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

Relevant Pages

  • Re: rwlocks, correctness over speed.
    ... Only variant to allowread recursion and ... ... by keeping a per thread count of shared acquired rwlocks. ... If a rwlock is currently locked as shared/read AND a thread is ... locks will only be granted to thread that already has a shared lock. ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... Only variant to allowread recursion and ... ... Most common cases of writer starvation 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 ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... Only variant to allowread recursion and ... ... keeping a per thread count of shared acquired rwlocks. ... If a rwlock is currently locked as shared/read AND a thread is blocked ... will only be granted to thread that already has a shared lock. ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... Only variant to allowread recursion and ... ... Most common cases of writer starvation 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 ...
    (freebsd-arch)
  • Re: rwlocks, correctness over speed.
    ... 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. ... I would still like to disallow recursion. ...
    (freebsd-arch)