I was recently invited to deliver a talk at an upcoming conference, and that meant I had to come up with a topic. I wrote up a talk description, but when I was done, I decided that I wanted to save it for this year’s C++ and Beyond. As a result, I now have a topic to announce for this December’s C&B:
Concurrent Data Structures and Standard C++
Concurrent data structures permit multiple writers to simultaneously modify a single data structure. Used properly, they can avoid scalability bottlenecks in multithreaded systems. Used improperly, they can decrease program performance.
There are no concurrent data structures in the C++98 standard library. The C++11 standard library is similarly bare, and C++14 is unlikely to change that. Nevertheless, concurrent data structures for C++ developers are widely available from sources such as Microsoft’s PPL, Intel’s TBB, and Boost. In this talk, I’ll examine the motivation and use cases for concurrent data structures, discuss their limitations, survey offerings common to PPL and TBB, and contrast concurrent APIs with those of seemingly similar serial counterparts (e.g.,
concurrent_vectorvs.std::vector). I’ll also explain why writing your own concurrent data structure is much more complicated and error-prone than most people initially imagine. (If you’re not familiar with the ABA problem, this presentation will explain why you should be.)
Scott
PS - I still don’t know what I’ll talk about at the other conference :-)
May 12, 2013 at 2:35 pm
This would be a great topic!
But I would like to see as well hints and advices how to (unit) test such structures and code or threaded code in general.
Simple scenarios are easy. But how to trigger the really tricky aspects? How to effectively shift one threads execution against a parallel running one? How to detect the interferrences between parallel running threads? Just showing that under certain conditions the code works, might be enough in some areas, but in life critical system this is not sufficient.
May 13, 2013 at 9:36 am
The problem of testing concurrent code would make a good session in its own right. It’s not the kind of thing for which unit testing is well suited. I’m not an expert in this area, but my impression is that the most promising way to approach the problem is the use of special tools that analyze the code either dynamically or statically to identify the possibility of race conditions, using the rules of the C++11 memory model as the basis for the analysis. Tools that I am aware of (but have no personal experience with) include Relacy Race Detector and thread-sanitizer, but there are several others.
I encourage people with recommendations for such tools or experience using them to share their information here.
May 25, 2013 at 5:20 pm
[…] has announced one of his prospective talks: “Concurrent Data Structures and Standard C++.” From his […]