So the C++0x standard has now been completed and has been submitted for final ratification. Whatever else has been changed in the standard, the single most important thing from my perspective is that C++0x standardizes its thread model. To date people have had to use add-on libraries, usually pthreads, suffering with various doubts and uncertainties due to there being no memory model. Moreover the lack of standard thread model has hindered the development of higher-level abstract models more appropriate for applications developers than shared-memory multi-threading.
Java has had a standard thread model since its inception. For the last 16 years people have been using this for applications programming and more and more coming to realize that shared-memory multi-threading is not a technology for applications programming. It is a technology that is infrastructure for creating higher level abstractions. Doug Lea in leading the JSR166 work has brought some of these to Java. Well you may have to wait till Java 8 before you get the best bits but most people are using JSR166 directly (even though it is an extra set of dependencies) or are using libraries such as GPars. In fact GPars is build on JSR166 providing even higher level abstraction such as actors, dataflow model, communicating sequential processes (CSP), and agents.
Amongst other JVM-based languages the move away from explicit use of shared- memory multi-threading is a rampant rush: Scala is using the Actor Model, there is the Akka library, Clojure is using agents - and software transactional memory though I think this is an aberration, it is a sticking plaster to try and make the shared-memory multi-threading model continue to be usable for applications programming in the face of increasing evidence that this model is not that usable and will not scale.
What about in the native code arena? Go is using what is effectively a minor variation on CSP: the process and message passing system of the goroutines is based on a single thread per process, synchronous message passing system that was developed independently of CSP but has very similar semantics. D has what is effectively Actor Model as its underlying model of concurrency and parallelism. This leaves the two major players in the native code arena: C and C++.
C is incorrigible, but then it is just a portable assembly language, so in a sense that is understandable. C perhaps should stay just as it is exactly because it is a portable assembly language, and serves a useful purpose because of it - C is an important language for writing system-level infrastructure that has to be portable. What is incomprehensible though is why applications programmers continue to use it. C is clearly far too low level a language for applications programmers to use, they should be using Python, Ruby, C++, D, Java, Groovy, Scala, Closure, . . . anything but C. In terms of concurrency and parallelism, C perhaps should stay as it is - though perhaps see if a language such as Go, with garbage collection and a standard thread/memory/concurrency/parallelism model, actually takes off as a replacement systems programming language.
Of course C++ is really just a systems programming language as well, but it does have some higher-level capabilities making it suitable for applications programming. Has D though already got to where where C++ can only hope to go in the future? Has C++ come to the "higher level abstractions" table too late. Can D gain traction in the market before C++ finally gets to the table?
It will be interesting to see if people using C++ just slide into continuing to use shared-memory multi-threading but using the standard rather than an add-in library or whether they see the light and take up libraries providing higher level abstractions such as Just::Thread Pro which provides Actor Model, Dataflow Model, and possibly agents in the future, or C++CSP2 which provides an authenticated CSP implementation for C++. Maybe instead people will begin an increasing move to using D which already has Actor Model and other higher level infrastructure in place.
C++ is definitely trailing the JVM-based languages, just now. Perhaps the new standard is an opportunity for C++ to re-enter the fold of appropriate languages? (Assuming people don't just continue with shared-memory multi- threading as an application programming technique.)
Lots of questions, currently no answers. Only time will tell. As usual.