msleep() on recursivly locked mutexes

Julian Elischer julian at elischer.org
Fri Apr 27 18:07:22 UTC 2007


Matthew Dillon wrote:
>     The real culprit here is passing held mutexes to unrelated procedures
>     in the first place because those procedures might have to block, in
>     order so those procedures can release and reacquire the mutex.
>     That's just bad coding in my view.  The unrelated procedure has no
>     clue as to what the mutex is or why it is being held and really has no
>     business messing with it.

[description of DFLY spinlocks removed for brevity]

> 
>     If I were to offer advise it would be: Just stop trying to mix water
>     and hot wax.  Stop holding mutexes across potentially blocking procedure
>     calls.  Stop passing mutexes into unrelated bits of code in order for
>     them to be released and reacquired somewhere deep in that code.  Just
>     doing that will probably solve all of the problems being reported.

Actually Matt, I don't think there is much argument here.. It has come to the time
where locking needs a big broom, and  I suspect that there will be such a broom
activated at BSDCan. There is some work going on (by john and others) to 
'unify and sanitise' the locking. We'll see where it goes.

Or is that wax and hot water?



More information about the freebsd-hackers mailing list