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:16:01

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

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
>

OK ,that's what I've had read yesterday too

>
> 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.
>

hmm - Anthony does also the unlock after the notification in the examples
of 'C++ Concurrency in Action' - anyway I've already changed the
implementation accordingly in branch develop.