Regarding parallelism: It seems that parallel algorithms are coming first:
http://www.open-std.org/JTC1/SC22/WG21/ ... fRegarding concurrency: Composable futures, task group, etc., are coming, too:
http://www.open-std.org/JTC1/SC22/WG21/ ... 01.htmlThe good news is that both Parallelism TS and Concurrency TS are on the fast track to approval:
http://isocpp.org/blog/2015/06/trip-rep ... meetingOne note on the concurrent containers -- these are non-trivial if you want a solution that will scale well into the future -- which includes working well with future hardware as well as future problems, with a design that will stand the test of time (we wouldn't necessarily want to end up with another vector<bool> or valarray...).One issue to take into account is transactional memory (instead of, say, locks -- which would defeat the purpose); Transactional Memory TS is very much worth a look in this context (as well as the Intel's TSX on the hardware side).Theoretically (and, as far as concurrency is concerned, getting the fundamentals right is not necessarily a bad idea before jumping right to the practical implementation) there are some unsolved problems here.For an illustration of what I mean and why is this important, I'd recommend "Unlocking Concurrency":
http://queue.acm.org/detail.cfm?id=1189288First, it's indeed highly recommended to use an existing, mature, battle-tested library solution (quality matters -- the flip-side being: there are only so many high-quality choices available, including folks / organizations willing to spend their time / resources to write and defend proposals in this area...):QuoteIt is possible to write a concurrent hash-map data structure using locks so that you get both concurrent read accesses and concurrent accesses to disjoint data. In fact, the recent Java 5 libraries provide a version of HashMap, called ConcurrentHashMap, that does exactly this. The code for ConcurrentHashMap, however, is significantly longer and more complicated than the version using coarse-grained locking. The algorithm was designed by threading experts and it went through a comprehensive public review process before it was added to the Java standard. In general, writing highly concurrent lock-based code such as ConcurrentHashMap is very complicated and bug prone and thereby introduces additional complexity to the software development process.However, at the same time -- and despite the occasional optimistic expectations -- in fact, having a concurrent hash map in the standard library doesn't (and wouldn't) make "concurrency with hash maps" a solved problem (if the programmers actually want composability -- which is pretty fundamental for programs that are to stand the test of time):QuoteAlthough highly concurrent libraries built using fine-grained locking can scale well, a developer doesn?t necessarily retain scalability after composing larger applications out of these libraries. As an example, assume the programmer wants to perform a composite operation that moves a value from one concurrent hash map to another, while maintaining the invariant that threads always see a key in either one hash map or the other, but never in neither. Implementing this requires that the programmer resort to coarse-grained locking, thus losing the scalability benefits of a concurrent hash map (figure 3A). To implement a scalable solution to this problem, the programmer must somehow reuse the fine-grained locking code hidden inside the implementation of the concurrent hash map.It remains to be seen if, say, HTM / STM is the way to go (and which design point -- or points -- along the continuum of choices is -- or are -- "right").But the point about locks stands -- if the wish is to have STL containers with locks, a strictly superior approach (complexity _and_ performance) is to recompile the workload as a single-threaded application, since using a locks-based "concurrent" data structure would completely and purposefully defeat any benefits anyway:
http://a248.e.akamai.net/f/1097/1823/7m ... 8/fig2.jpg