On Fri, 27 Apr 2007, Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer <[EMAIL PROTECTED]>:
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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
