Re: msleep() on recursivly locked mutexes

2007/4/26, Julian Elischer <julian@xxxxxxxxxxxx>:
The reason that mutexes ever recurse in the first place is usually because one
piece of code calls itself (or a related piece of code) in a blind manner.. in other
words, it doesn't know it is doing so. The whole concept of recursing mutexes is a bit
gross. The concept of blindly unwinding them is I think just asking for trouble.

Further the idea that holding a mutex "except for when we sleep" is a generally
bright idea is also a bit odd to me.. If you hold a mutex and release it
during sleep you probably should invalidate all assumptions you made during the
period before you slept as whatever you were protecting has possibly been raped
while you slept. I have seen too many instances where people just called msleep
and dropped the mutex they held, picked it up again on wakeup, and then blithely
continued on without checking what happened while they were asleep.

Basically, the idea you cannot hold "blocking" locks (mutexes and
rwlocks) while sleeping, cames from the difference there is behind
turnstiles and sleepqueues.

Turnstiles are thought to serve syncronous events, for short period of
time (or rather short) while sleepqueues are thought to serve
asyncronous events, so that the path to be protected can be
definitively bigger. If you fit in the situation you have to call
first a blocking lock and later a sleeping lock, probabilly you are
just using a wrong locking strategy and you should really revisit it.

As you mention, it is not always possible to drop the blocking lock
before to sleep since you can break your critical path and free the
way for races of various genre. Even unlocking Giant, that is
auto-magically done by sleeping primitives, can lead to very difficult
to discover races (I can remind one in tty code, old of some months,
that can be a good proof-of-concept for that).

Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: msleep() on recursivly locked mutexes
    ... Further the idea that holding a mutex "except for when we sleep" is a ... release it during sleep you probably should invalidate all assumptions ... This is basically when I need to exit mutexes. ... it is not always possible to drop the blocking lock ...
    (freebsd-hackers)
  • Re: blockable sleep lock (sleep mutex) 16
    ... as sleep mutex. ... sleeping actually means calling "*sleep ... Locks I've created I properly destroyed (at least I think I ...
    (freebsd-hackers)
  • Re: blockable sleep lock (sleep mutex) 16
    ... but you can't do an M_WAITOK malloc while holding a mutex. ... In the scheduler, sleeping and blocking are actually quite different. ... Holding a mutex while sleeping could result in a mutex being held for a long time. ...
    (freebsd-hackers)
  • Re: weird thread behavior on itanium/hp-ux with pthread
    ... You are misreading the output of tusc. ... did go to sleep first. ... Since "something_happened" occurs outside of the mutex, ... while (sleeping) ...
    (comp.programming.threads)
  • Re: weird thread behavior on itanium/hp-ux with pthread
    ... You are misreading the output of tusc. ... did go to sleep first. ... Since "something_happened" occurs outside of the mutex, ... while (sleeping) ...
    (comp.programming.threads)