[threads] Deadlock?
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(); } I tried it with and without the lock (in the 2nd snippet) but the 2nd snippet code is never getting called and just seems to vanish when wait is specified. When wait isn't specified, it all works. (Non-wait is just the same thing without any of the locks/conditions.) Any thoughts on where to look to proceed or what documents to read ? Thanks, and apologies for the inexperience. New to boost..
On 03/29/11 00:05, The Novice Coder wrote:
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(); }
First of all, I wonder what your reason is to go with boost's threading over Qt's facilities, given that your application is already tightly bound into using Qt (you're using their event loop and events). Are you sure that the Qt's event loop is running? Are both threads executing their own event loop? (You should check this one, it depends on you if you want each thread to run an event loop, or do something else. In any case, make sure you understand the semantics of QCoreApplication::postEvent and how these events are delivered). Finally, you code is missing some context to understand what you're trying to achieve. I have no idea what the "qtService" stands for, not what "s" is, if there are any classes derived from the QObject, how you intend to use the events, etc etc. Cheers, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/
On Mon, 04 Apr 2011 13:08:51 +0200, Jan Kundrát wrote:
First of all, I wonder what your reason is to go with boost's threading over Qt's facilities, given that your application is already tightly bound into using Qt (you're using their event loop and events).
Well, disclaimer on that - Wasn't my idea. My task is to get it to work. But basically, there's the GUI section of code, and the work section of code and the two have very little to do with each other, as there's 3 different GUI tool kits that are used depending on the project. The "configurator" (which runs in the background) calls the toolkit with a list of windows that need to be created.
Are you sure that the Qt's event loop is running? Are both threads executing their own event loop? (You should check this one, it depends on you if you want each thread to run an event loop, or do something else. In any case, make sure you understand the semantics of QCoreApplication::postEvent and how these events are delivered).
Hmmm. That's definitely something I need to look into. It seems to be deadlocking on the mutex's, but it might be stopping there. The code reportedly works fine in Linux, Mac, and XP, but chokes on Win 7. (I'm the short-straw dev who's forced to use 7.) I'll read up here next.
Finally, you code is missing some context to understand what you're trying to achieve. I have no idea what the "qtService" stands for, not what "s" is, if there are any classes derived from the QObject, how you intend to use the events, etc etc.
From what I understand, the basic gist is that a piece of code, like the GUI creation, MUST run from the main thread, and this code takes care of that, switching the context to the main thread (Or whatever thread is requested). As for what qtService means, I haven't the foggiest. It's definitely NOT descriptive enough for my tastes, as it seems to be one step away from qtGoDoSomething.
Cheers, Jan
Thanks for the feedback! =) Time to hit the manuals again. (Probably both figuratively and literally)
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
participants (3)
-
Gottlob Frege -
Jan Kundrát -
The Novice Coder