Subject: Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>
From: Peter Dimov (lists_at_[hidden])
Date: 2014-05-05 13:56:31
Niall Douglas wrote:
> Firstly, permits are a notification object, not a serialisation object. If
> you have some predicate P whose state you are changing you must protect it
> with a mutex, just like any other code. This is why permit.wait() takes a
> locked mutex.
But you do have a wait() function that takes nothing?
> Reworking your example thusly:
> Initially P is 0 and p_mutex is unlocked.
> Tc1, Tc2 lock p_mutex and call wait.
> Tp1 locks p_mutex, sets P=1 and calls notify_one. Upon Tp1 releasing the
> mutex, Tc1 is unblocked with mutex locked, returns from wait, but is
> immediately suspended by the scheduler for unfathomable scheduling
> reasons, like its code causing a page fault.
> Tp2 tries to set P=1, but gets blocked on the mutex being held by Tc1.
> When Tc1 is resumed and eventually unlocks the mutex, everything else
> proceeds as normal.
This assumes that notify_one is called before releasing the mutex. Condition
variables allow notify_one outside the mutex. Is this use not supported by
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk