On 4 May 2014 at 23:25, Peter Dimov wrote:
A non-consuming permit looks quite like a Win32 event object yes, except it has stronger guarantees useful for many-waiter many-signaller situations.
What are these stronger guarantees?
They are listed at the top of the documentation page, but in essence a manual reset Win32 event object state change doesn't make strong guarantees about what happens to waiters. A permit grant, if non-consuming, will block until all waiting threads at the point of grant have been released. I believe the Win32 SetEvent() doesn't block. The fact it does block can be useful - I am still unsure whether grant ought to return the number of threads released by the grant or not, hence asking here for feedback. You also get guarantees about destroying the object during waits or grants which can be very useful for patching up poorly written code to be race free.
A consuming permit looks totally different to Win32 event objects.
You do know that WIn32 events can be auto-reset or manual-reset, right? Is not an auto-reset event the same as a consuming permit?
It's time to put on my sheepish hat. You are absolutely correct, and I don't know how I cognitively disconnected from auto-reset event objects being semantically similar to consuming permits. The only explanation I think could be the number of years it has been since I last used a win32 event object. I'll get the docs updated soon to reflect this, but yes, you're right permits are similar to a user space portable shared memory capable windows event object. I think they're useful in some situations where existing facilities force you to roll something like them, and as we all know rolling your own threading code is always risky. This permit implementation has taken a surprising amount of effort given how simple they supposedly are e.g. ensuring they don't starve some waiting threads under heavy load over others, that sort of thing. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/