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

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

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/