Boost logo

Boost :

Subject: Re: [boost] [thread] countdown_latch
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2013-05-25 09:51:57

On 25/05/2013 15.26, Vicente J. Botet Escriba wrote:
> Le 25/05/13 14:45, Gaetano Mendola a écrit :
>> On 21/05/2013 07.13, Vicente J. Botet Escriba wrote:
>>> Le 20/05/13 22:09, 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.
>>>>> The change set is To
>>>>> see the sources, you would need to update the trunk or to take a
>>>>> look at
>>>>> Please let me know what do you think.
>>>> What's the plan for this countdown_latch is it candidate to be included
>>>> in version 1.54 ?
>>> No, documentation and tests are missing. I hope it will be ready for
>>> 1.55. This and other addition will be experimental and its interface
>>> will be subject to some changes.
>>> E.g. I have not decided yet how to provide cyclic latches.
>> Given the fact I have my own implementation of a latch, can you please
>> explain what a cyclic latch is, to see if my latch already provide
>> the feature. I will propose my implementation of latch.
> boost::barrier resets the counter once all the threads synchronize, so
> that the barrier can be reused again. In order to do that the barrier
> store the initial counter value and reuse it at each cycle.
> I don't know if I all the latched must support this feature (possibly by
> a configuration parameter) or if it is better to have a separated
> cyclic_latch.

So what are you proposing is a latch that as soon have reached 0 it will
reset to the initial value and permitting a wait to continue without
stopping if it arrives after the reset or to block waiting for a reset.
My latch doesn't provide such feature, but isn't enough to keep a
counter (reset_counter) increased at each reset and decreased at each
wait() (before exiting from it). This way the wait shall be a blocking
call if the "reset counter" is > 0.

I would make two different names: latch and cyclic_latch

I'm also to remove the precondition counter > 0 on the latc::count_down.

Gaetano Mendola

Boost list run by bdawes at, gregod at, cpdaniel at, john at