Subject: Re: [boost] [thread] countdown_latch
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2013-05-16 16:25:45
On 16/05/2013 21.27, Vicente J. Botet Escriba wrote:
> Le 15/05/13 19:26, Gaetano Mendola a écrit :
>> 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.
>>>
>>
>> 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.
> You can built on top of latch a class that has a latch and a specific
> counter for T2 (the latch is initialized to 1 and the counter to N. The
> thread T1 just wait on the latch, and the thread T1 counts down the
> thread specific counter (without any need to use locks). Once this
> specific counter is zero the class count_down the latch.
>>
>> 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.
>>
> What is the expected behavior of the threads T2 and T3 if they
> count_down more than N times?
> IMHO, you should build your own class that takes care of your specific
> constraints.
The expected behaviour is that if you do a count_down on a latch that is
zero already the operation doesn't have any effect.
>> In my opinion the solution of both use cases is to remove the
>> precondition.
>>
> Could you show how removing the precondition can help to implement the
> use cases you have presented?
Simply T2 and T3 can continue to do count_down without keep track if
the counter has reached zero or not.
Regards
Gaetano Mendola