Lewis Baker

The implementation would likely be closer to that of `async_auto_reset_event` which is essentially a binary-semaphore. This implementation keeps track of the count of calls to 'set' and 'wait' by combining...

The implementation of `async_auto_reset_event` actually has an implicit mutex/lock built in to it. The first thread to increment either 'set' or 'wait' count such that both are non-zero acquires the...

Yes. I think the compare_exchange failure case can be changed to relaxed too

The diff looks to be taking the right approach. I've added a few comments to the commit. With regards to the ever-reducing number of concurrent operations, the approach I've been...

> This puts the responsibilty which scheduler to use into the releasing function... Actually, the responsibility of which scheduler to use is given to the caller of `wait()`. eg. ```c++...

I have a use-case for the current saturating behaviour of `async_auto_reset_event`. This is useful for cases where there might be many updates to a shared data-structure and after each update...

A somewhat cumbersome way of implementing the when_any() pattern such that the first operation to complete is a "winner" and the others are "losers" and should be cancelled: ```c++ task...

The other main use-case of `when_any()` is to act as an event loop, allowing code to handle completion of a number of concurrently executing tasks serially in the order they...

If you just want to check whether a task completed within a certain time then you can just query the time both before and after the task completes and check...

Yes, looking at the test it is a potential recursion problem. The call to `event.set()` resumes the awaiting coroutine inline inside the call to `set()`. This is both a flaw...