Re: msleep() on recursivly locked mutexes

On Fri, 27 Apr 2007, Hans Petter Selasky wrote:

On Friday 27 April 2007 15:14, Daniel Eischen wrote:

When you hold a mutex, it should be for a very short time. And
I agree with the other comment that all drivers should be multi-thread
safe, so we shouldn't add cruft to allow for non MT-safe drivers.

Yes, and no.

Mutexes are used to get the CPU out of the code. Therefore you should not
lock/unlock all the time, to ensure that the locked time is as short as
possible. Because then you get double work checking the state after that you
lock a mutex again. Surely, in a "static" environment there is nothing to
check. But in a dynamic environment you need to check that "descriptors" of
all kinds are still present, after that you lock a mutex. Unlocking a mutex
allows "anything" to happen. Keeping a mutex locked prevents certain things
from happening.

If you need to prevent "things" from happening, and it is at more
of a macro level than micro level, then you probably want a condvar
or barrier sort of synchroninzation, or possibly a rwlock. When
the thread currently in the guts of your driver exits, he releases
the CV or rwlock and allows another thread to enter (which possibly
causes another "anything" to happen).

--
DE
_______________________________________________
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: [PATCH RFD] alternative kobject release wait mechanism
    ... devices and to provide a set of mutually-exclusive services to the ... and the drivers need a way to unbind even while waiting ... to acquire the mutex. ... It also wakes up all threads that are blocked trying to lock the ...
    (Linux-Kernel)
  • [BUG] drivers/video/sis: deadlock introduced by "fbdev: add mutex for fb_mmap locking"
    ... The kernel stopped at(output via serial port): ... Add a mutex to avoid a circular locking problem between the mm layer ... # Device Drivers ...
    (Linux-Kernel)
  • Re: [PATCH] kdesu broken
    ... No, bz 13841 isn't about pty's, it's about usb serial. ... it should call drv->closewithin the mutex on the error path if the ... tty_block_til_readyfails without which you get a leak on a few drivers ... Most serial drivers don't try and do open clean up in openinstead they ...
    (Linux-Kernel)
  • Re: [BUG] cdev_put() race condition
    ... cdev, then the spinlock has to be replaced by a mutex. ... Note that if we ever allow drivers to hook in their own release callback, ... So why is V4L different than the rest of the kernel in that it wishes to ...
    (Linux-Kernel)
  • =?UTF-8?q?Re:_Re:_matroxfb:_fix_regression_with_uninitalized_fb=5Finfo->mm=5Flock_mutex_(sec
    ... Remove redundant locking by the mm_lock mutex before a second head of ... The mm_lock mutex is used only inside the fb_mmapfunction and driver's specific code. ... All other drivers just have, let's say, inefficient code - calling a function which is called just ... The mm_lock patch converted this inefficient code into broken code. ...
    (Linux-Kernel)