Re: [boost] [thread] thread interruption semantics

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2007-11-14 11:13:21

"Preston A. Elder" wrote:
> 
> On Wed, 14 Nov 2007 12:27:44 +0000, Preston A. Elder wrote:
> 
> > This would be easily fixed by getting it to lock the internal lock on
> > unlock (before the notify_all).  Doing so would mean that the notify_all
> > could not happen until B is in the wait.
> 
> And now I think about it, it should probably be a notify_one - there is
> no point waking up all threads when only one will be able to acquire the
> lock after an unlock.

You would then need to be a bit more careful in timed_lock().

  if (!try_lock()) {
    mutex::scoped_lock sl(m_internal); 
    while (!try_lock()) 
      if (!m_cond.timed_wait(sl)) 
        return try_lock();
  }

Alternatively, on timeout, you can return failure but only after 
resignaling condvar. (Timeout on condvar is allowed to "steal" 
concurrent signal.)

unlock:

  m_mutex.unlock();
  { mutex::scoped_lock sl(m_internal); }
  m_cond.notify_one();

Also note that such wrapping doesn't preserve destruction safety of
Mutex ala POSIX pthread_mutex_t. To preserve it, m_mutex.unlock() must
be done  after signaling (or signaling must be done while holding
m_internal lock which itself must be destruction safe as
pthread_mutex_t).

regards,
alexander.