conditional_variable_any::any fails to release recursive_mutex when mutex has been acquired by the same thread more than one time

[brad_wade@…]

I'm having a problem where the following code used to work in boost 1.33.0 to 1.34.1 (I have removed code for brevity). However, the code now deadlocks. It appears that the problem occurs because calling wait on a conditional_variable_any variable does not release a recursive_mutex that has been acquired by the same thread more than one time.

[brad_wade@…]

Code example

[brad_wade@…]

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

[Anthony Williams]

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@…]

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@…]

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.