Subject: [Threads-devel] [thread] condition_variable_any::wait and recursive_mutex
From: Rob Moore (Rob.Moore_at_[hidden])
Date: 2010-09-06 06:22:58
Boost version 1.40. Compiler VC9.
I have found an issue where condition_variable_any::wait does not fully
unlock a recursive_mutex if its recursion count is greater than 1. Is
this deliberate? The simple code below reproduces the issue - the
program will deadlock.
std::cout << "Worker 2\n";
while (g_endThread == false)
std::cout << "Worker 2 starting wait\n";
g_whatToWaitFor.wait(lock); // **** Will wait for ever ****
std::cout << "Worker 1\n";
int _tmain(int /*argc*/, _TCHAR* /*argv*/)
std::cout << "Main thread starting sleep\n";
std::cout << "Main thread finished sleep\n";
g_endThread = true;
std::cout << "Main thread waiting for worker\n";
This code outputs:
Main thread starting sleep
Worker 2 starting wait
Main thread finished sleep
I am aware of the adopt_lock argument to the lock constructor, but that
doesn't work if the thread hasn't already locked the mutex. What I
think I need is one of 2 things:
1. A wait function on conditional_variable_any that will completely
unlock and then relock a recursive_mutex. This would be ideal.
2. A new argument to the lock constructor that has the same behaviour as
adopt_lock if the thread already has the mutex. If the thread does not
have the mutex the new constructor will locks the mutex (same as the
basic constructor with no extra argument). This would allow me to have
a class with multiple methods that can call each other and where any
method could be the first one to be called in any given thread.
Am I missing something?
Micromill Electronics Limited trading as Cobham Surveillance, Waterberry, Drive, Waterlooville, Hampshire, PO7 7XX. www.cobham.com
Registered Office: Brook Road, Wimborne, Dorset, BH21 2BJ, England
Registered Number: 1456922
THIS EMAIL AND ANY ATTACHED FILES ARE CONFIDENTIAL AND MAY BE LEGALLY PRIVILEGED
If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited.
If you have received this transmission in error please notify the sender immediately and then delete this e-mail.
Please consider the environment before printing this email.