Re: [boost] [thread] countdown_latch

Subject: Re: [boost] [thread] countdown_latch
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2013-05-14 15:21:48

On 14/05/2013 13.09, Rob Stewart wrote:
> On May 13, 2013, at 2:27 PM, Michael Marcin <mike.marcin_at_[hidden]> wrote:
>
>> On 5/13/13 2:19 PM, Gaetano Mendola wrote:
>>> On 13/05/2013 02.46, Rob Stewart wrote:
>>>> On May 12, 2013, at 6:45 PM, Michael Marcin <mike.marcin_at_[hidden]>
>>>> wrote:
>>>>
>>>>> On 5/12/2013 6:49 AM, Rob Stewart wrote:
>>>>>> On May 11, 2013, at 5:29 PM, Gaetano Mendola <mendola_at_[hidden]> wrote:
>>>>>>
>>>>>>> On 21/04/2013 12.54, Rob Stewart wrote:
>>>>>>>> IOW, you'd create a barrier for two threads and both thread_proc() and the constructor would wait() on the barrier. Once both threads
>>>>>>>> have called wait(), they are both released.
>>>>>>>
>>>>>>> As said that's create a not needed "wait" on the thread body, what the OP (and me for the matter) needs is that *only* thread creator is blocked waiting for the threads to arrive at certain point of the execution.
>>>>>>
>>>>>> It seems to me that wait is inconsequential relative to the cost of creating a thread. If this were part of the thread creation process,
>>>>>> an option to thread's constructor, say, there would be some
>>>>>> convenience, but the performance difference doesn't seem worthwhile.
>>>>>> Have I missed something?
>>>>>
>>>>> The created thread is already executing when it gets to the latch. Why would you want to introduce synchronization, and potentially block the thread, where none is needed?
>
> Having only the one tool is easier to understand, and given that the wait would be very short, relative to the high cost of creating a thread, I don't know that the performance gain is worthwhile.
>
>>>> Is the latch to just cause the creator to block until the created thread begins, or is it more general purpose to cause a number of threads to wait until they are all ready?
>>>
>>> The latch is to just cause the creator to block until the created thread begins.
>>> At the moment with boost off-the-shelf you can achieve it using a barrier but doing so you are blocking the thread as well, what me and the OP needs is that the thread creator will eventualy block waiting for the thread not the other way around. You can achieve it
>>> using a syncronization mechanims named "latch":
>
> Thus, a new tool for a little optimization. Is the benefit provably useful?
>
>>> boost::latch myLatch(1);
>>>
>>> myLatch.count_down();  /// This is not a blocking operation
>>>
>>> myLatch.wait(); /// This is blocking if a count_down() was not issued
>>>
>>> of course latch is implemented with condition.
>
> For that purpose, the names, and even the approach, seem wrong. Ideally, I'd expect a constructor argument to boost::thread to control this. Then, a wrapper function can coordinate with the constructor to release it when the wrapper runs, just before it invokes the user's callable.
>
> Lacking that, a class named "gate", with "wait" and "open" member functions, would be more readable.
>
>> More generally you can use the latch to block N threads until N events occur. But the threads signaling the events don't have to block.
>
> OK. The gate usage, above, is a degenerate case of this. Still, the names and approach or not ideal.
>
>>  From the Java docs:
>>
>> A CountDownLatch is a versatile synchronization tool and can be used for a number of purposes. A CountDownLatch initialized with a count of one serves as a simple on/off latch, or gate: all threads invoking await wait at the gate until it is opened by a thread invoking countDown(). A CountDownLatch initialized to N can be used to make one thread wait until N threads have completed some action, or some action has been completed N times.
>>
>> A useful property of a CountDownLatch is that it doesn't require that threads calling countDown wait for the count to reach zero before proceeding, it simply prevents any thread from proceeding past an await until all threads could pass.
>
> Thank you for that. I don't like the "count down" part of the name, at least of the release operation, and while "await" is fine, it isn't helpful to use a new verb. Why not parallel barrier and condition_variable, and use "wait" and "notify"?

Given it has a clearly inspiration on Java one I would leave it like it
it now with the excpetion to permit count_down even if the counter is
zero already.

Regards
Gaetano Mendola