[asveikau]

> C++ developer is somewhat comfortable with traditional concurrency toolkit like threads.

As somebody who has used threads a lot and written code in kernel mode etc. something about this scratches me the wrong way.

The traditional concurrency toolkit has some issues. Being experienced with them can make you somewhat jaded against them. In particular, the standard way to solve problems in that mode of thinking is to introduce locks, and experienced people know all the problems that locks have, and that the "solution" is harmful in the extreme.

So it is acceptable for such a programmer to want more options, standardized. I would even argue that this is more important than introducing std::mutex, std::thread, or std::atomic, because you can say that in the pre-C++11 era nonportable interfaces like pthreads or win32 were already working OK for people that chose to use them.

[jcelerier]

> In particular, the standard way to solve problems in that mode of thinking is to introduce locks

nowadays I mostly see lock-free queues and message passing across threads, it's trivial to do with a few nice libraries