On Mon, Mar 28, 2011 at 6:05 PM, The Novice Coder
I'm working with boost:threads, and am having what appears to be a deadlock issue. I'm not sure if the lock is something I'm doing, or if it's my lack of understanding of boost::condition_variable.
The code deadlocks on this snippit:
if( wait) { // lock the condition, add the event, wait for the condition, and get the return value! boost::mutex::scoped_lock lk(serviceMutex_); clearException(); returnValue_ = 0; qApp->postEvent(temp_this, temp_event, Qt::HighEventPriority); serviceCondition_.wait(lk); }
Where wait is specified by the caller to wait for the other thread to return. In the service request thread has this snippet:
{ boost::mutex::scoped_lock lk( serviceMutex_); returnValue_ = qtService(s->getCommand()); serviceCondition_.notify_one(); }
Is the service request thread holding the serviceMutex lock, and sitting inside s->getCommand() waiting for something to be posted? So the main thread can't grab the lock, and thus can't post the command, and thus the service-side waits forever? What if the code got the command before the lock:
{ Command c = s->getCommand(); boost::mutex::scoped_lock lk( serviceMutex_); returnValue_ = qtService(c); serviceCondition_.notify_one(); }
Or maybe qtService(c) can also be before the lock - is the lock protecting something, or just for notification? I really don't know, just making guesses from experience. Tony