msleep() on recursivly locked mutexes

[Daniel Eischen]

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

> On Thursday 26 April 2007 23:50, Attilio Rao wrote:
>> 2007/4/26, Julian Elischer <julian at elischer.org>:
>>> 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.

I know there are reasons why we have msleep(), but use of msleep()
and recursive mutexes should raise be frowned upon.  If you want to
sleep, that's why we have condvar's.  And if you are releasing a
synchronization lock in a different thread, then why aren't you
using condvar's wrapped by mutexes() to protect the internal state?

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.

-- 
DE