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