Thanks Alexander for the pointer to this long and interesting discussion. I'll check my design whether I could get rid of the recursive mutexes in order to reduce the probability of not holding invariants when the wait() is called, especially since the code still doesn't behave correctly, even after the Boost bug is fixed :) William, unfortunately I don't have a small testcase for the bug and it seems that it will be too time-consuming for me to try to prepare a small "working" testcase. Thanks for confirming the bug report (it makes me feel better that the debugging time was not wasted). --Yulik. -----Original Message----- From: William E. Kempf [mailto:wekempf@cox.net] Sent: Monday, May 05, 2003 6:44 PM To: Boost-Users@yahoogroups.com Subject: Re: [Boost-Users] bug in pthreads implementation of recursive_mutex Feldman, Yulik said:
Hi,
It looks that there is a bug in .../boost_1_30_0/libs/thread/src/recursive_mutex.cpp. The bug shows in the pthreads implementation of the recursive_mutex when the mutex is used with the "condition" synchronization primitive. Here is the description of the bug:
You're evaluation of the bug is correct. I'll fix this in CVS shortly. Do you maybe have a test case for this that I could add to the regression tests? 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. -- William E. Kempf Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/