$include_dir="/home/hyper-archives/boost-users/include"; include("$include_dir/msg-header.inc") ?>
From: Christian Henning (chhenning_at_[hidden])
Date: 2005-08-10 13:06:20
Hi there, seems the attention span for my last question is over. ;-) I
also think that my subject was misleading. My question isn't about
terminating, completing, or canceling a thread. It's about putting a
thread in a blocked state.
Please consider the following code. All functions, except for the
run(), are called by the GUI thread.
The _oThread object is RAII-object ( Resource Allocation is Initialization  ).
// Only called by GUI thread
fvAsynchronousSequencer::fvAsynchronousSequencer()
  : _oThread                    ( )
  , _bTerminateSequencerThread  ( false )
  , _bStop( false )
{
  _oThread.create( this, _run );
}
// Only called by GUI thread
fvAsynchronousSequencer::~fvAsynchronousSequencer()
     throw()
{
  _bTerminateSequencerThread = true;
  // wake up the thread, if necessary
  _oRunCondition.notify_one();
  // wait until the thread is terminated
  {
     boost::mutex::scoped_lock oLock( _oTerminateMutex );
     _oTerminateCond.wait( oLock );
  }
}
// Only called by GUI thread
     void
fvAsynchronousSequencer::start()
{
  _bStop = false;
  _oRunCondition.notify_one();
}
// Only called by GUI thread
     void
fvAsynchronousSequencer::stop()
     throw()
{
  _bStop = true;
 // I would like to wait until the _oThread is a in blocked position.
}
     void
fvAsynchronousSequencer::_run()
     throw()
{
  boost::mutex::scoped_lock oLock( _oRunMutex );
  // Wait until someone calls start()
  _oRunCondition.wait( oLock );
  do
  {
    // do something useful
     while( _bStop )
        _oRunCondition.wait( oLock );
  } while( !_bTerminateSequencerThread );
  // now finish destructing the sequencer
  _oTerminateCond.notify_one();
}
So, I will ask again my question. Is there a way that the stop() will
only return when the worker thread in in blocked state? Right now, I
just set _bStop to true and stop() returns. This approach is of course
rife for deadlocks.
Thanks again,
Christian