Boost logo

Threads-Devel :

Subject: [Threads-devel] wait/notify_one problem
From: Siegal, Sara (ssiegal_at_[hidden])
Date: 2009-06-15 15:15:00


I'm trying to use condition variables in a pretty classic producer/consumer problem. I've done some research that makes me think condition variables are the way to go, but I can't seem to get the implementation right. The producer and consumer are both member functions of a class which has the mutex (readyListMutex) as a class member.

The Producer:
void WFOVProcessor::frameCallback(int32_t frame) {
  cout << "WFOVProcessor::frameCallback" << endl;
    CaptureRequest req;
    // ...fill in the CaptureRequest data structure here...
  cout << "WFOVProcessor::frameCallback scoped_lock" << endl; boost::mutex::scoped_lock lock(m_readyListMutex);
  cout << "WFOVProcessor::frameCallback push_back" << endl;
    m_readyList.push_back( req );
  cout << "WFOVProcessor::frameCallback notify_one" << endl;
    lock.unlock( );
    m_readyListCondition.notify_one( );

The Consumer:
    while ( true ) {
      cout << "WFOVProcessor::background before readyLock" << endl;
        boost::mutex::scoped_lock readyLock(m_readyListMutex);
      cout << "WFOVProcessor::background after readyLock" << endl;
        if ( ! m_running ) break;
        if ( m_readyList.size( ) == 0 ) {
            do {
              cout << "before WFOVProcessor::background loop m_readyListCondition.wait" << endl;
              cout << "after WFOVProcessor::background loop m_readyListCondition.wait" << endl;
            } while( !m_readyList.size( ) && m_running );
            if ( ! m_running ) break;
        CaptureRequest req = m_readyList[0];
        m_readyList.pop_front( );
          // something with the request...

The output when I run my program (32 bit linux):
WFOVProcessor::background before readyLock
WFOVProcessor::background after readyLock
before WFOVProcessor::background loop m_readyListCondition.wait WFOVProcessor::frameCallback
WFOVProcessor::frameCallback scoped_lock

When the producer tries to obtain the lock, it waits forever. What am I doing wrong? Is the order incorrect? For debugging purposes, is it possible to query the state of a mutex?

Thanks in advance!

Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at