Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-12 16:57:13

Alexander Terekhov wrote:
> http://groups.google.com/groups?selm=3f0c0a3d%40usenet01.boi.hp.com

"Had I been following 1003.1d when they added this silly attribute I would
have objected. Since it was removed, clearly there were plenty of others
with sense available. ;-) The critical aspect of mutex performance is in
the NONBLOCKING case, where timeout is irrelevant. The cost of setting up
for a timeout on the blocking path is tiny compared to the scheduling
operations, and would only occur when calling pthread_mutex_timedlock().
(Which presumably one would never do on a mutex that would have been set
PTHREAD_TIMEOUT_DISALLOWED.)" -- Butenhof

>> Does it? I think that the Boost implementation tries to operate
>> "correctly" for lock_count() > 1, but I may have misread the code.
>
> I meant windows thing that is used in Metrowerks [if I got Howard
> right] and pthread-win32. IIRC, I've "voiced objection" at the time
> the boost::condition and recursive locks were discussed here. Uhmm,
> can't find it...

http://lists.boost.org/MailArchives/boost-users/msg03835.php
http://lists.boost.org/MailArchives/boost-users/msg03838.php

"BTW, Mr. Terekhov does provide a good resource in his posting on this
subject.  I disagree with some points in the thread he posted, but it is
quite true that you absolutely must gaurantee that invariants hold at the
point cond.wait() is called, and that doing so is complicated by the use
of recursive locks.  Either avoid recursive locks entirely, avoid
condition variables with recursive mutexes, or be very sure of the design
and the state of your invariants." -- Kempf

http://groups.google.com/groups?threadm=34293AAA.69FB%40opentext.com

(the aforementioned resource)

"Unfortunately, recursive mutexes are a bad idea. They're expedient, and
it is, sometimes, useful to have them available so you don't need to
make code thread-safe. But there's ALWAYS a better, more maintainable,
and far more efficient alternative that uses normal mutexes. For a long
time, I regretted having introduced recursive mutexes into DCE (which is
what caused them to become part of XSH5). I've since reached a state of
relative inner peace, however. They CAN BE convenient. If used properly
(that is, with careful analysis and design), recursive mutexes can be an
effective way to use code that's never performance-critical in threaded
programs. (But if you've got code that's ever on a hot path, avoid
recursive mutexes like the plague that they are!)" -- Butenhof

http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com

and the rest of the thread.

Executive summary: mutexes protect temporarily broken invariants.
condition::wait() can safely unlock once because the code that called wait()
knows this to be safe (it locked the mutex). However multiple unlockings are
unsafe, because if you knew they'd be safe, you'd have had enough knowledge
to avoid the recursive_mutex, too.

> but here's something: ;-)
>
> http://groups.google.com/groups?selm=3D484233.AD1E26E8%40web.de

"AFAICS, boost::condition's use of >>boost::recursive_mutex<<
is totally broken [and its utterly brain-dead/java-like N->0 ``spin out
feature'' aside for a moment], to begin with." -- Terekhov