Subject: Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-05 15:21:45
On 5 May 2014 at 20:30, Bjorn Reese wrote:
> > you will have to use grant() and revoke() instead. When deciding to
> > substitute permits for condition variables, you will need to decide
> > carefully which kind of permit is the correct substitute."
> Is it correct to say that permits are level-triggered, whereas condition
> variables are edge-triggered?
Correct. Though, technically speaking, a condvar + mutex combo is
also level triggered if and only if the mutex is always held by all
waiters and all notifiers while they run.
> > "Permit objects are actually very similar to a void promise/future
> > i.e. they act as a reusable promise/future pair but without
> > transporting any value or exception state, just the permission to
> So a permit is a future without value :)
Also lighter weight, shared memory capable, no malloc etc.
> > ermit_reference.pdf). As such, they can be very useful for situations
> > where a promise/future is too heavy (permits can spin instead of
> > sleep, plus they need not be repeatedly constructed and destructed)."
> It may be a good idea to have example code of a spinning future
> (possibly by using expected<>)
Remind me: is proposed expected<T> still essentially the value and
exception transport mechanism of promise<T>/future<T>? It may have
evolved since, or I got its intent wrong.
> Another useful example could be a one-to-one latch (as in N3666.)
I had thought Alasdair's latch a sort of inverted semaphore? Can you
clarify what you mean by one to one latch?
> > https://github.com/ned14/thread/tree/permit_object
> I suggest that permit<> is renamed to basic_permit<>
>, and permit_c
> to permit. permit_nc should have a more meaningful name, such as
> singleshot_permit or permit_once.
How does boost::gate sound for a non-consuming permit? So:
typedef basic_permit<true> permit;
typedef basic_permit<false> gate;
If gate is no good, we could use boost::event, though I personally
think that is a bit too likely to clash.
-- 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