Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>

Subject: Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>
From: Bjorn Reese (breese_at_[hidden])
Date: 2014-05-05 14:30:35

On 05/03/2014 11:13 PM, Niall Douglas 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?

> "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 :)

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

Another useful example could be a one-to-one latch (as in N3666.)

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