http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862
--- Comment #14 from bartek 'basz' szurgot
2011-10-26 13:42:29 UTC ---
uhum - i missed that one... :/
ok then - looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862#c10 is a
working solution. :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862
--- Comment #11 from bartek 'basz' szurgot
2011-10-26 12:41:34 UTC ---
i'm not sure about uncaught_exception(). i remember reading in Herb Sutter's
that it's usage should be avoided, since it has some flaw, that makes it's
return value unsure. bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862
--- Comment #9 from bartek 'basz' szurgot
2011-10-26 06:39:15 UTC ---
implementation is nice. i think there is still one more problem to be fixed,
though. namely the line:
~_Unlock() { _M_lock.lock(); }
since lock() may throw an exception, which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862
--- Comment #6 from basz 2011-10-25
14:45:29 UTC ---
yes - you're right. i got this note all wrong. thanks for the clarifications
and links!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862
--- Comment #4 from basz 2011-10-25
13:51:45 UTC ---
the most recent document on C++0x i have is N3290. according to it it is so for
condition_variable (30.5.1.9 and 30.5.1.10), but description for wait() of
condition_variable_any is a bit more c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862
--- Comment #1 from basz 2011-10-25
10:28:09 UTC ---
Created attachment 25611
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25611
patch fixing the problem
unlocking local mutex, before locking back user's lock solves the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862
Bug #: 50862
Summary: deadlock in std::condition_variable_any
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P
