Am 05.09.2015 3:59 nachm. schrieb "Oliver Kowalke" : 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) What about two fibers running on different OS threads? Are they not allowed
to synchronize with each other? _______________________________________________
Unsubscribe & other changes: