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