Re: [Threads-devel] wait/notify_one problem

Subject: Re: [Threads-devel] wait/notify_one problem
From: Stefan Küppers (kueppers_web_at_[hidden])
Date: 2009-06-17 02:56:02

Hi,
first, I'm not a boost-expert.

But I found some helpfull information here:
http://aszt.inf.elte.hu/~gsd/klagenfurt/material/ch03s06.html

In my opinion a construction like this

f() {
  mutex.lock();
   do_something();
  mutex.unlock();
}

is allways critical, because the mutex is not unlocked, if "do_something();" throws an exception.
Therefore using the "Resource Allocation Is Initialization idiom" where the mutex is locked
in a constructor of a class and unlcocked, when the class leaves scope and its destructor is called.

Please attach the complete source file, which allows a deeper look.

Best Regards,
Stefan Küppers.

> -----Ursprüngliche Nachricht-----
> Von: "Siegal, Sara" <ssiegal_at_[hidden]>
> Gesendet: 15.06.09 21:37:59
> An: "threads-devel_at_[hidden]" <threads-devel_at_[hidden]>
> Betreff: [Threads-devel] wait/notify_one problem

> Hi,
> 
> 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;
>                 m_readyListCondition.wait(readyLock);
>               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( );
> 	  // ...do 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 mailing list
> threads-devel_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/threads-devel
> 

___________________________________________________________________
WEB.DE FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und 
Telefonanschluss für 17,95 Euro/mtl.! http://produkte.web.de/go/02/