Re: msleep() on recursivly locked mutexes

Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
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

That is not always correct. If you run your code in a separate thread/taskqueue, then you simply wait for this thread/taskqueue to complete somewhere else. This is basically when I need to exit mutexes.

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.

The suggestion is just for convenience. Usually you don't have a recursed mutex to sleep on. It is just to catch some rare cases where you will end up with a doubly locked mutex, which is not part of the ordinary code path. I don't have such cases in the kernel of the new USB stack, but there are some cases in the USB device drivers, which is due to some mutex locking moves. Those I can fix.

I don't think you got my point.
I can understand this is for convenience and I can understand why you want it but definitively you should never have a recursed mutex, That's all.
This is why msleep(), condvar() and lockmgr() panics if a recursed mutex is passed. Definitively, we mustn't cater a misbehaving approach with extra-hack in the kernel code.

Attilio
_______________________________________________
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 generally ... first a blocking lock and later a sleeping lock, ... it is not always possible to drop the blocking lock ...
    (freebsd-hackers)
  • 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)
  • [PATCH] applesmc - fix crash when activating a led trigger on the keyboard backlight
    ... keyboard backlight feature. ... after activating this trigger the machine will either lock-up ... This is caused by the fact applesmc_backlight_set locks a mutex (or more ... safe to sleep in the brightness_set handler of a led_class device (it is ...
    (Linux-Kernel)
  • RE: Do you really "sleep" when blocked on a mutex?
    ... means that if a thread is holding a lock, ... Do you really "sleep" when blocked on a mutex? ... sched_wakeup which eventually calls setrunqueue()? ...
    (freebsd-hackers)
  • Re: 6.0 Witness squawk
    ... >> I'm almost finished porting my AoE ... is it ok to sleep with a mutex held? ... it works like this in the driver. ...
    (freebsd-arch)