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_lockboost::mutex lk(mutex_); count_down(lk); }
and
void count_down_and_wait() { boost::unique_lockboost::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.
Also I would add a new method to boost::detail::counter
bool dec_and_notify_all_if_value(const std::size a_value) { if (--value_ == a_value) { cond_.notify_all(); return true; } return false; }
This way you can further simplify the count_down(unique_lock<mutex> &lk) method:
//lk is here only to assure it's a thread safe call bool count_down(unique_lock<mutex> &lk) /// pre_condition (count_.value_ > 0) { BOOST_ASSERT(count_.value_ > 0); return count_.dec_and_notify_all_if_value(0); }
When this function would be used?
Look at the new version of bool count_down(unique_lock<mutex> &lk); I have expressed above. Regards Gaetano Mendola