> The wait_for method is why we have a condition variable at all. If it weren’t for that guy, we could have used std::atomic‘s wait and notify_all methods.
No, the std::mutex is the reason you have a condition variable. Never mix std::atomic with std::mutex-and-friends, you are very likely introducing race conditions that way.
This seems to omit the main point of it, though? That the compiler turns a function into a state machine that can restart from any of its suspension points. I guess that's the "state" variable, but what I'm talking about is what it contains and the partially compiler-generated code that deals with it.
C++ async is unfortunately a "bring your own runtime" sort of model (for now), but it does handle the part that would be incredibly tedious by hand, building above mentioned state machine.
That's the co_await/co_yield/co_routine stuff, which this isn't talking about--this is talking about the std::future-et-al logic, which predates C++ coroutines by almost a decade.
If the objective with using async is performance and scalability then you should almost always "bring your own runtime". Bringing your own runtime is the main reason you might want to use async.
Delegating the runtime nerfs many of the benefits that async can offer. If you are going to delegate the runtime it offers relatively little compared to just using threads.
C++ async model is too complicated (and not cost free as claimed, since it allocates memory for the coroutine state) and as such it wasn't widely adopted. I don't see any code using C++ async (apart from libraries implementing "tasks" in various forms). At this point I view it as a failed experiment. My bet is that executors are going to replace async completely.
No, the std::mutex is the reason you have a condition variable. Never mix std::atomic with std::mutex-and-friends, you are very likely introducing race conditions that way.
C++ async is unfortunately a "bring your own runtime" sort of model (for now), but it does handle the part that would be incredibly tedious by hand, building above mentioned state machine.
Delegating the runtime nerfs many of the benefits that async can offer. If you are going to delegate the runtime it offers relatively little compared to just using threads.
Heap allocation is not required, just the default.
You can do static allocation if you wish, though it is a little more complicated than typical static allocation due to the relative unpredictability.