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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/