Subject: Re: [boost] [thread] countdown_latch
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2013-05-15 13:26:10


On 27/04/2013 09.05, Vicente J. Botet Escriba wrote:
> Le 22/04/13 10:16, Michael Marcin a écrit :
>> On 4/21/2013 11:30 PM, Vicente J. Botet Escriba wrote:
>>
> Hi,
>> Back on topic of latches and barriers.
>> I was reading up on Java's CyclicBarrier and found its await return
>> value pretty interesting and probably fairly free to implement.
>>
>> "...each invocation of await() returns the arrival index of that
>> thread at the barrier."
>>
>> "the arrival index of the current thread, where index getParties() - 1
>> indicates the first to arrive and zero indicates the last to arrive."
>>
>> To do this in boost::thread::barrier you would just have to cache
>> m_count right after the decrement and return it instead of the current
>> true/false.
>>
>>
>
> Yes, boost::barrier return true for the last wait. The change would be
> quite simple, but what would be he utility of such an index?
>
> I have implemented a first prototype of a latch class that could be used
> also as a barrier. I don't know if the name is the good one then.
> I have also implemented a completion_latch class that is able to call a
> function when the counter reaches zero. I'm not satisfied with the
> current implementation as it needs a lot of synchronization.
>
> The change set is https://svn.boost.org/trac/boost/changeset/84055. To
> see the sources, you would need to update the trunk or to take a look at
> https://svn.boost.org/svn/boost/trunk/boost/thread/
>
> Please let me know what do you think.

As reported in another reply I believe as it is misses some features.

Immagine indeed the following two scenarios:

Thread T1 needs to wait that another thread T2 have executed a certain
operation at least N times.
In this case (with the precondition of count_down that counter > 0) T2
has to track how many count_down it has executed
(knowing then the initial value and there is no way to know given a
latch his current value) or issue a "try_wait" before the each
count_down and this IMHO seems a bit awkward.

Rubbing salt to the wound imagine if T1 has to wait that T2 and T3
have done a certain operation N times (in total).
In this way T2 and T3 have to sync at start and communicate each other
how many count_down they have executed, the trick of issuing a
"try_wait" in this case doesn't work.

In my opinion the solution of both use cases is to remove the
precondition.

Regards
Gaetano Mendola