Boost logo

Boost :

Subject: Re: [boost] [thread] countdown_latch
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2013-05-14 02:34:17


On 5/14/2013 12:46 AM, Vicente J. Botet Escriba wrote:
>
> I have an uncommitted version where
>
> bool count_down(unique_lock<mutex> &lk)
> /// pre_condition (count_.value_ > 0)
> {
> BOOST_ASSERT(count_.value_ > 0);
> if (--count_.value_ == 0)
> {
> lk.unlock();
> count_.cond_.notify_all(); // unlocked !!!
> return true;
> }
> return false;
> }
>
> Maybe I'm wrong and I'm doing premature optimization and it is better to
> use lock_guard and don't unlock before notifying.
> As you point it is in any case clearer.
>
> Measures would be needed :(
>
> Thanks for your interest,

bool count_down(unique_lock<mutex> &lk)
/// pre_condition (count_.value_ > 0)
{
   BOOST_ASSERT(count_.value_ > 0);
   if (--count_.value_ == 0)
   {
     lk.unlock();
---> interleave here <---
     count_.cond_.notify_all(); // unlocked !!!
     return true;
   }
   return false;
}

What can happen with the explicit unlock?
If waiting threads wake spuriously and interleave where marked above I
suppose they just acquire the lock see that the counter is zero and return.
Since that thread is no longer waiting on the cv it is no longer
notified by notify_all.
The count_down thread has to execute slightly more code (the difference
between unique_lock and lock_guard).

What can happen without the explicit unlock?
We'll notify the waiting threads but we still have the mutex locked.
I think worst case they wake immediately, fail to acquire the lock and
immediately go back to sleep.
I've been led to believe that this sleep shouldn't really happen, rather
the threads should spinlock for the short time until the lock is
released in the unique_lock destructor.
Additionally there seems to be no guarantee the waiting threads will
even wake before the unique_lock destructor.

The first seems better but I am no an expert.
Looking around I've found a couple of other c++ countdown latch
implementations none of them seem to do this which may or more not mean
anything.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk