Le 14/05/13 00:44, Gaetano Mendola a écrit :
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_lockboost::mutex lk(mutex_); .... return; }
you are optimizing doing this:
void foo() { boost::unique_lockboost::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).
Sorry Gaetano, I have an uncommitted version where bool count_down(unique_lock<mutex> &lk) /// pre_condition (count_.value_ > 0) { BOOST_ASSERT(count_.value_ > 0); if (--count_.value_ == 0) { lk.unlock(); count_.cond_.notify_all(); // unlocked !!! return true; } return false; } Maybe I'm wrong and I'm doing premature optimization and it is better to use lock_guard and don't unlock before notifying. As you point it is in any case clearer. Measures would be needed :( Thanks for your interest, Vicente