Re: [boost] [thread] countdown_latch

Subject: Re: [boost] [thread] countdown_latch
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2013-05-13 18:44:15

On 13/05/2013 23.13, Vicente J. Botet Escriba wrote:
> Le 13/05/13 21:05, Gaetano Mendola a écrit :
>> On 12/05/2013 01.03, Vicente J. Botet Escriba wrote:
>>> Le 11/05/13 23:25, Gaetano Mendola a écrit :
>>>> On 27/04/2013 09.05, Vicente J. Botet Escriba wrote:
>>>>> The change set is https://svn.boost.org/trac/boost/changeset/84055. To
>>>>> see the sources, you would need to update the trunk or to take a
>>>>> look at
>>>>> https://svn.boost.org/svn/boost/trunk/boost/thread/
>>>>>
>>>>> Please let me know what do you think.
>>>>
>>>> Is the explicit lk.unlock() inside the
>>>>
>>>> bool count_down(unique_lock<mutex> &lk);
>>>>
>>>> needed ?
>>>>
>>>
>>>> I see the two places where it's called are:
>>>>
>>>> void count_down()
>>>> {
>>>>   boost::unique_lock<boost::mutex> lk(mutex_);
>>>>   count_down(lk);
>>>> }
>>>>
>>>> and
>>>>
>>>> void count_down_and_wait()
>>>> {
>>>>   boost::unique_lock<boost::mutex> lk(mutex_);
>>>>   if (count_down(lk))
>>>>   {
>>>>     return;
>>>>   }
>>>>   count_.cond_.wait(lk, detail::counter_is_zero(count_));
>>>> }
>>>>
>>>> in both cases the unique_lock does the job, or I'm missing
>>>> something?
>>> Not really. It is an optimization.
>>
>> Let me understand, instead of:
>>
>> - long jump
>> - unlock inside boost::~unique_lock
>>
>> with your optimization the following will happen:optimization:
>>
>> - explicit unlock
>> - long jump
>> - boost::~unique_lock
>>
>> is that optimization realy worth ? I mean a mutex unlock is hundred
>> of instructions, involving even a syscall, while a long jump is just
>> a long jump.
>>
>> Do you have any evidence of the gain you have doing so?
>>
>> Also while we talk about optimization why not use lock_guard when
>> possible ?
>>
>> > The mutex don't need to be lock when the condition is notified.
>>
>> Of course is not needed, but my point was another one.
>>
> I didn't expressed myself clearly. The optimization consist in unlocking
> as soon as possible not in executing less instructions.

Unlocking as soon as possible is something it should happen whenever is 
possible, but basically you are doing this kind of optimization:

instead of

void foo() {
   boost::unique_lock<boost::mutex> lk(mutex_);
   ....
   return;
}

you are optimizing doing this:

void foo() {
   boost::unique_lock<boost::mutex> lk(mutex_);
   ...
   lk.unlock;
   return;
}

and I'm asking, is it worth?  Do you have an evidence of it ?
Having say that do whatever you believe is better in terms of clarity
and correctness.
I have seen also that in a couple of points the unique_lock can be
replaced by a lock_guard (and possibly declared const).

> I meant in addition to the use in count_down.

At the moment only in there.

Regards
Gaetano Mendola