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

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-09-05 20:06:46

Le 05/09/15 16:03, Thomas Heller a écrit :
> Am 05.09.2015 3:59 nachm. schrieb "Oliver Kowalke" <oliver.kowalke_at_[hidden]
>> :
>>
>> 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)
> What about two fibers running on different OS threads? Are they not allowed
> to synchronize with each other?
>
>
I expect that the answer is yes, otherwise I don't know what we are 
reviewing.
How Boost.Fiber can optimize the synchronization of two fibers on the 
same threads is another issue.
So you are right, fibers should be able to run in parallel.

Vicente