----- Original Message ----- From: "Anthony Williams" <anthony_w.geo@yahoo.com> To: <boost@lists.boost.org> 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@wanadoo.fr> 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