Description

In this episode, Billy O'Neal and Stephan T. Lavavej (S.T.L.) talk about the Standard Template Library for multithreading, and how to use it properly. We would love to hear some feedback on this episode! If you liked it, let us know and we may make a follow up!

Thank you for the nice episode,At the end, Billy mentioned about rewriting async. I've heard that of one visual studio c++ library fundamental differences from libc++ and libstdc++ in terms of async is that its default policy does some intelligent work underneath to figure out when and how the function is going to be called. What has really changed and does it work the same or better now?

@Anton Bikineev: I asked Billy your question (he works right next to me), and this was his response:

We get the Windows thread pool to do our dirty work. That'd be QueueUserWorkItem on Windows XP, or CreateThreadpoolWork/SubmitThreadpoolWork on Vista+.

The version shipping with VS2015 and VS "15" is somewhat nonconforming in that it doesn't implement launch::async correctly -- it doesn't spawn a real thread and always uses the thread pool. This has been fixed in the next major version of the libraries.

(I didn't implement and have really only done minor bugfixes to the version shipping in VS2015/VS "15" but the version in the next major libraries version I rewrote from scratch)

Appreciate the video, but there's a recurrring message of having to be super careful with concurrency. Everyone knows that it's easy to do it wrong, and when it goes wrong it's tough to put right. And it's a difficult learning curve - here we have the guys chatting about using threads, then using mutexes, oh and maybe you can toss in an atomic or a condition variable. Or maybe you don't - if you do be *sure* you know it's the right thing to do. Or... well, maybe you want to use async, or futures, or whatever else is out there.

I don't expect Microsoft to teach the world to do concurrency. I get it that these videos aren't even trying to do that. So where do you go to learn the ropes and not get into a tangle? Is the C++ Concurrency In Action the bible for this, or has that now been superseded? Am I correct in thinking it was written before a lot of this had been standardised? We tend to shy away from concurrency at my shop, but that's just sticking heads in the sand. Better to at least know what can be done and then decide not to do it.