On Sat, Sep 5, 2015 at 4:08 PM, Agustín K-ballo Bergé
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