Subject: Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-05 15:06:00
On 5 May 2014 at 20:56, Peter Dimov 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?
That wait never sleeps, so wakeups cannot be lost.
There is actually an internal facility for sleeping waits without a
mutex, but it is deliberately not documented as you shouldn't use it
(it's only there because it made the Windows implementation much more
> > 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
Consuming permits let you grant either with or without the mutex.
Non-consuming permits will deadlock if you grant holding the mutex
because of the guarantee of blocking until the release of all current
If you grant outside of the mutex, you accept that if your preferred
waiter doesn't wake and claim its mutex before another wake occurs,
you intend the grant to be lost. As I mentioned, sometimes you want
that, sometimes you don't. I assume you'd like this sort of stuff
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk