Boost C++ Libraries: Ticket #2219: conditional_variable_any::any fails to release recursive_mutex when mutex has been acquired by the same thread more than one time

attachment set

brad_wade@… — Mon, 18 Aug 2008 23:00:03 GMT

attachment → boost_bug.txt

Code example

brad_wade@… — Tue, 19 Aug 2008 15:43:45 GMT

I should note that this error occurs in Visual Studio 2005--I haven't tested other compilers or platforms.

status changed; resolution set

Anthony Williams — Tue, 02 Sep 2008 10:08:02 GMT

status new → closed
resolution → wontfix

This works as designed. condition_variably_any::wait() calls unlock on the supplied mutex. For a recursive mutex this only does one level of unlocking.

Completely unlocking a recursive mutex is not safe in the general case. I did not realise that the old boost::condition supported it. This facility has never been tested in the boost::condition tests. I will add it to the list of breaking changes.

brad_wade@… — Tue, 02 Sep 2008 17:34:16 GMT

I was afraid of that. The old boost::condition would unlock the mutex however many times it had been acquired and then would restore the lock count appropriately when the wait() function completed. I was pleasantly surprised when I saw that it worked. Looks like I'll need to find a workaround... Thanks for your reply.

gpeele@… — Fri, 16 Jan 2009 19:09:11 GMT

The core issue seems to be the POSIX implementation of recursive_mutex. There is not enough information provided by POSIX to reliably save and restore the lock count, and it's not clear how much performance would have to be sacrificed to manage this state in the Boost recursive_mutex implementation. Since nothing else would require this lock state information, I assume that's why this design choice was chosen.

As mentioned, calling lock() and unlock() multiple times inside condition_variable_any in would be unsafe, especially since this is very specific to recursive_mutex and may break the behavior for other mutex types.