RE: [Boost-Users] bug in pthreads implementation of recursive_mut ex
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/
We have an application which uses boost threads and omnithreads. A developer encountered a problem where threads would deadlock when a condition variable was wait()-ed in a boost-created thread. Every once in a while the unlock was not seen by the CORBA created threads. The problem went away when we applied Yulik's patch. Thanks, Yulik. -John Van Horne Feldman, Yulik wrote:
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/
*Yahoo! Groups Sponsor* http://rd.yahoo.com/M=249982.3179269.4495679.1261774/D=egroupweb/S=1705006788:HM/A=1524963/R=0/*http://hits.411web.com/cgi-bin/autoredir?camp=556&lineid=3179269&prop=egroupweb&pos=HM
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 the Yahoo! Terms of Service http://docs.yahoo.com/info/terms/.
[Non-text portions of this message have been removed]
participants (2)
-
Feldman, Yulik -
John Van Horne