Re: msleep() on recursivly locked mutexes

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?

_______________________________________________
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

  • [PATCH 5/8] PM: fix new mutex-locking bug in the PM core
    ... dpm_suspendfails to reacquire a mutex it should be holding. ...
    (Linux-Kernel)
  • Re: sched_yield() makes OpenLDAP slow
    ... When a mutex is unlocked, one of the *waiting* threads at the time of the unlock must acquire it, and the scheduling policy can determine that. ... In all likelihood, what tends to happen is that either the thread that had the mutex previously still has time left in its timeslice and is allowed to keep running and reacquire the mutex, or another thread is woken up but doesn't reacquire the mutex before the original thread carries on and acquires it, and therefore goes back to sleep. ...
    (Linux-Kernel)
Quantcast