Re: [boost] Boost.Fiber mini-review September 4-13

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-05 09:59:05

2015-09-05 15:12 GMT+02:00 Agustín K-ballo Bergé <kaballo86_at_[hidden]>:

> On 9/5/2015 3:42 AM, Oliver Kowalke wrote:
>
>> 2015-09-04 21:05 GMT+02:00 Agustín K-ballo Bergé <kaballo86_at_[hidden]>:
>>
>> 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)