Re: [boost] [thread] Does this condition wrapper perform betterthan the wrapped condition?

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-19 18:12:16

----- Original Message ----- 
From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, May 19, 2008 10:47 PM
Subject: Re: [boost] [thread] Does this condition wrapper perform betterthan 
the wrapped condition?

> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>
>> In the Join library I have see the following idiom
>>
>>     mutex mtx;
>>     condition_variable cond;
>>     unsigned num_blocked;
>>
>>     void foo() {
>>         unique_lock l(mtx);
>>         ++num_blocked;
>>         cond.wait(lock);
>>         --num_blocked;
>>
>>         // ...
>>     }
>>
>>     void foo() {
>>         unique_lock l(mtx);
>>         // ...
>>         if (num_blocked > 0) cond.notify_one();
>>         // ...
>>     }
>>
>> Does this perform better in some contexts? if yes in which ones?
>
> It really shouldn't do. The check is part of the notify.

On windows notify_one is defined as:

void notify_one()
{
    if(detail::interlocked_read_acquire(&total_count))
    {
        boost::mutex::scoped_lock internal_lock(internal_mutex);
        // ...
    }
}

detail::interlocked_read_acquire do a system call. This should be more 
expensive than doing a test >0, isn't it?

With pthreads notify_one is defined as

inline void condition_variable::notify_one()
{
    BOOST_VERIFY(!pthread_cond_signal(&cond));
}

Does pthread_cond_signal needs to protect its own counter from multiple 
threads? Could some one point to the pthread_cond_signal source code, or how 
to get it?

Note that this idiom is only applicable if the application use the same lock 
to wait and to notify, which is quite current.

Yigong, could you confirm some performance improvements on your approach?

Vicente