Boost logo

Boost :

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?

> >
> I suggest that permit<> is renamed to basic_permit<>

Makes sense.

>, 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at