2015-09-05 15:12 GMT+02:00 Agustín K-ballo Bergé
On 9/5/2015 3:42 AM, Oliver Kowalke wrote:
2015-09-04 21:05 GMT+02:00 Agustín K-ballo Bergé
: Although holding a mutex while firing on the condition variable is
considered bad practice, so this would be even better:
do you have a reference?
Well, it's not exactly new and it is baked into the design of `std::condition_variable`. I guess this will have to do for reference: http://en.cppreference.com/w/cpp/thread/condition_variable/notify_one
in Butenhof's examples pthread_cond_signal/pthread_cond_broadcast are
always called if front of pthread_mutex_unlock
Alas pthread specifies different semantics than the standard library, and there you are actually expected to hold the lock if you want predictable scheduling. I hear pthread won't actually wake up any threads then (which wouldn't be able to make progress otherwise), but rather switch them from waiting on the cv to waiting on the mutex to avoid useless context switches; when the mutex is finally unlocked the thread will finally wake up.
keep in mind that fibers do not run in parallel - in a single thread the sequence of unique_lock< mutex > lk( mtx); ... lk.unlock(); cnd.notify_one(); is the same as unique_lock< mutex > lk( mtx); ... cnd.notify_one(); lk.unlock(); (no parallelism like threads)