Boost logo

Boost :

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


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