msleep() on recursivly locked mutexes

Daniel Eischen deischen at
Fri Apr 27 18:36:24 UTC 2007

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).


More information about the freebsd-hackers mailing list