Re: rwlocks, correctness over speed.

2007/11/24, Robert Watson <rwatson@xxxxxxxxxxx>:

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.

I think however that Stephan is just referring to the readers
recursion (as we are doing) that if present should be just in few
points.
If we want todo a radical switch of this genre this is the right
moment, just before rwlock became too widespread.

I have a patch against witness which would check for readers recursion
and panic, I will post in the night or tomorrow.

Thanks,
Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
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 ... ... 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 ... I would still like to disallow recursion. ...
    (freebsd-arch)
  • 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 ... ... 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.
    ... 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)