Subject: Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-04 21:29:56
On 4 May 2014 at 23:25, Peter Dimov wrote:
> > A non-consuming permit looks quite like a Win32 event object yes, except
> > it has stronger guarantees useful for many-waiter many-signaller
> > situations.
> What are these stronger guarantees?
They are listed at the top of the documentation page, but in essence
a manual reset Win32 event object state change doesn't make strong
guarantees about what happens to waiters. A permit grant, if
non-consuming, will block until all waiting threads at the point of
grant have been released. I believe the Win32 SetEvent() doesn't
block. The fact it does block can be useful - I am still unsure
whether grant ought to return the number of threads released by the
grant or not, hence asking here for feedback.
You also get guarantees about destroying the object during waits or
grants which can be very useful for patching up poorly written code
to be race free.
> > A consuming permit looks totally different to Win32 event objects.
> You do know that WIn32 events can be auto-reset or manual-reset, right? Is
> not an auto-reset event the same as a consuming permit?
It's time to put on my sheepish hat.
You are absolutely correct, and I don't know how I cognitively
disconnected from auto-reset event objects being semantically similar
to consuming permits. The only explanation I think could be the
number of years it has been since I last used a win32 event object.
I'll get the docs updated soon to reflect this, but yes, you're right
permits are similar to a user space portable shared memory capable
windows event object. I think they're useful in some situations where
existing facilities force you to roll something like them, and as we
all know rolling your own threading code is always risky. This permit
implementation has taken a surprising amount of effort given how
simple they supposedly are e.g. ensuring they don't starve some
waiting threads under heavy load over others, that sort of thing.
-- 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