Re: boost.asem seeking endorsement

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2023-03-08 13:05:17

On Wed, Mar 8, 2023, at 2:28 AM, Klemens Morgenstern via Boost wrote:
> Channels - which are Experimental.

Channels do indeed cover the use cases represented by an asynchronous "condition variable" and "semaphore", and much more besides. A "condition variable" is an unbuffered channel, a "semaphore" is a channel with buffer size N, and a "mutex' is a channel with buffer size 1.

IMHO "experimental" is not a reason to avoid using channels if you have these use cases. "Experimental" is just an in-your-face warning that I don't guarantee the same level of API and behavioural stability as other parts of the library. Even so, I don't make breaking changes to their interface lightly. Eventually they will migrate into the main asio namespace.

Where channels *have* been limited is that they have required C++17 or later. However, from boost 1.82 they will work with C++11 and up (albeit with some limitations on functionality, but enough to cover the aforementioned use cases).

I may also consider in the future adding some algorithms over channels, to encapsulate some common usage patterns that are identified (e.g. using an RAII approach to pair sends and receives).

> He also said he's thinking about adding something akin to my mutex.

Yes, and my current view is that an asynchronous "mutex" does not add sufficient value over just using a channel either.

On the other hand, an asynchronous readers/writers lock (aka rwlock), is something I do see a lot of additional value in, due to the complexity involved in implementing it and particularly if it is upgradeable. I have been considering adding something along those lines in a future release.

Cheers,
Chris