Re: [boost] [thread] countdown_latch

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

On 26/05/2013 09.53, Vicente J. Botet Escriba wrote:
> Le 25/05/13 15:51, Gaetano Mendola a écrit :
>> 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 :
>>>>>>
>>>>>> 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
> Thanks for your advice.
> The alternative is to have a bool parameter on the constructor and make
> use of a "restore counter" when "reset counter" is > 0 which is not too
> expensive. This needs however to store another integer for the "restore
> counter". I want to be sure that this doesn't adds any additional
> constraint to the class.
>>
>> I'm also to remove the precondition counter > 0 on the latc::count_down.
>>
> I don't see yet the case of a thread using countdown several times the
> same latch as a valid use case. But maybe if you post a concrete (real)
> example, it could make me change.

Do you really need a real example?

I don't have a real example but again, having two threads calling
latch::count_down on the same latch instance is going to be an headache
for the user, immagine a multi producer/single consumer application 
where the consumer  as to start when at least N items are ready.

Yes sure they can implement their own Latch taking care of not calling
the count_down on the internal latch, for the matter seeing how hard is
to implement a latch they can even implement one from scratch.

At least throw an exception on an already zeroed latch instead to make 
the counter to assume a 2^64 − 1 value (making the wait a blocking
call again).

To the other side can you please tell me why you prefer to keep the
precondition breaking the principle of least surprise? Consider that a
CountDownLatch is an already concept in Java and the count_down in there
is implemented without the precondition.

Regards
Gaetano Mendola