|
Boost : |
Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: AgustÃn K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-09-05 11:08:55
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'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.
Regards,
-- AgustÃn K-ballo Bergé.- http://talesofcpp.fusionfenix.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk