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

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-09-06 15:38:59

On Sat, Sep 5, 2015 at 4:08 PM, Agustín K-ballo Bergé
<kaballo86_at_[hidden]> wrote:
> On 9/5/2015 10:47 AM, Peter Dimov wrote:
>>
>> Agustín K-ballo Bergé wrote:
>>
>>> 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 don't think that's true. The ability to notify without holding the
>> lock comes from pthreads. It's not a C++ invention, it's a pthread
>> invention; you're most definitely not expected to hold the lock.
>
>
> Agreed, but on the other hand it appears pthreads gives special semantics to
> notifications while the lock is hold. The reference talks about "predictable
> scheduling".
>

It is not really about special semantics, but it is a consequence of
other POSIX guarantees. Waiters are waken up in FIFO order (at least
under realtime FIFO scheduling), but if the signaling is done outside
the critical section, a late thread might acquire the critical section
(and consume a resource) after the condition as become true, but
before older waiters had a chance to acquire it. This might be
particularly important with realtime systems.

>> It's also more efficient because otherwise the awakened thread would
>> immediately block on the mutex.
>
>
> Nod, this is explained in the article linked before.
>
>>> 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.
>>
>>
>> Some pthreads implementations supposedly have this optimization, but not
>> all; and if you notify without holding the mutex, the thread would
>> proceed immediately.
>
>
> Your guess is as good as mine. I'm not a pthread standard expert, and that
> last comment was just hearsay on my part.
>

IIRC, at least glibc doesn't perform this optimization anymore.
For more details on this topic, you can search for  'wait morphing'.

HTH,

-- gpd