Sat Dec 4 00:43:00 GMT 2010
On 3 December 2010 09:58, Jonathan Wakely wrote:
> 2) if a try_lock fails we call unlock on the failed lock, we should
> only unlock the ones that succeeded
This incorrect behaviour is actually tested by
30_threads/try_lock/2.cc which verifies that it can re-acquire a lock
that was held prior to a call to try_lock.
30.4.3p2 is quite clear that if locking an argument fails, unlock is
called for all *prior* arguments, not for the failed lock (which might
have failed via an exception, not only because the lock is held.) My
new implementation causes that (invalid) test to fail.
The test is doubly bad, because it exits while holding mutexes, which
is undefined behaviour (220.127.116.11.1p5)
Patch coming soon ...
More information about the Libstdc++