msleep() on recursivly locked mutexes

Attilio Rao attilio at freebsd.org
Thu Apr 26 21:50:17 UTC 2007


2007/4/26, Julian Elischer <julian at elischer.org>:
> 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


More information about the freebsd-hackers mailing list