Subject: Re: [boost] [thread] countdown_latch
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-26 11:30:09
Le 26/05/13 15:07, Gaetano Mendola a Ã©crit :
> 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
>>>>>>> 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
>>>>> 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
>>> So what are you proposing is a latch that as soon have reached 0 it
>>> 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
>> 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?
Yes. As having a real example we could see if the solution you propose
would be used by the user or if it would implement its own class to
solve the problem more efficiently.
> 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.
I will not use a latch for that. I would build a at least n messages on
the queue data type and use the usual wait on this queue.
> 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).
Throwing an exception would need the same kind of check, which I want to
avoid.. The single option I think is acceptable is the try_count_down
but before adding it I want to have a valid use case and check how this
try_count_down would make the application code better.
> 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.
Java is not the first language on which these kind of mechanism are
used. I used them long time ago in C.
C++ is not Java. C++ interfaces use to use Require clauses that must be
ensured by the user so that the implementation can be as efficient as
I have used this terms as their are part of a standard C++ proposal and
the proposal has as I would expect this require clause. BTW, I'm open
and considering to use wait and notify which are more in line with the
C++ current interfaces.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk