Re: [boost] [thread] countdown_latch

Subject: Re: [boost] [thread] countdown_latch
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-26 16:01:29

Le 26/05/13 19:20, Gaetano Mendola a écrit :
> On 26/05/2013 17.30, Vicente J. Botet Escriba wrote:
>> 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
>>>>>>>>> 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?
>>>
>> 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.
>
> If the buffer is a general purpose buffer the wait on it will return as
> soon someone puts stuffs on it. As you know there are multiple way to
> achieve the same even without the usage of latch.
>
> I'm fine with leaving the precondition after all people have to read
> the manual, I have also see you have added a BOOST_ASSERT( count_ > 0).
Great.
>
> About the cyclic_latch instead of the bool to drive the counter reset
> I would template the latch using two different policies for reset or
> not, then I would expose a typedef of it, something like this:
>
> template <class COUNTER_POLICY>
> class Latch {
>
>     bool count_down(unique_lock<mutex> &lk)
>     /// pre_condition (count_ > 0)
>     {
>       BOOST_ASSERT(count_ > 0);
>       if (--count_ == 0)
>       {
>         counter_policy_.reset(count_);
>         ++generation_;
>         lk.unlock();
>         cond_.notify_all();
>         return true;
>       }
>       return false;
>     }
>
>   private:
>     COUNTER_POLICY  counter_policy_;
> };
>
>
> typedef Latch<NoResetPolicy> latch;
> typedef Latch<ResetPolicy> cyclic_latch;
>
>

Would the base Latch class be public? if not, this is an implementation 
detail and is equivalent to having two classes but sharing a common 
implementation.
Shouldn't the base latch make use of EBO?

Best,
Vicente