msleep() on recursivly locked mutexes

Daniel Eischen deischen at freebsd.org
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).

-- 
DE


More information about the freebsd-hackers mailing list