Re: [Boost-users] [threads] Deadlock?

Subject: Re: [Boost-users] [threads] Deadlock?
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2011-04-05 00:04:05

On Mon, Mar 28, 2011 at 6:05 PM, The Novice Coder
<boost_at_[hidden]> wrote:
> 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