06-19-2008
Sophia Antipolis - A Standards Meeting Reviewed (Part 2)
Concurrency is a hot topic, not just for C++0x but across IT in general as the hardware we use on a daily basis transitions from the serial single-core world many of us grew up with into the parallel multi-core world on sale today. Entry level desktop PCs have been dual core for some time now, and even mobile phone platforms are routinely dealing with multiple CPUs. While the legacy of single-core hardware will take some time to fade completely, modern software development must address the fact the it is generally now running on machines that genuinely exectute in parallel with a shared memory architecture.
This challenge goes to the heart of the C++ specification which is designed in terms of an abstract machine that all implementations must emulate. The existing standard specifies a machine largely inherited from C with no notion of parallel execution, so the very foundation the standard is built on needs updating!
The lowest level of this work is known as the memory model. This part of the standard defines the notion of parallel execution, threads and race conditions, and the dependency between the order of operations that a compiler must enforce. To an extent this limits the range of optimizations available to compilers compared to a single-threaded execution, but also gives developers the guarantees they need in order to write programs without unexpected side-effects, such as the infamous double-checked lock idiom that frequently fails to work as expected in the presence of optimizations (some performed by the CPU itself, rescheduling instructions after compilation!)
Most of the memory model work has been resolved at earlier meetings, and focus has moved towards libraries and higher-level abstractions to make concurrent development practical. However, even at this meeting a number of fundamental proposals were adopted. Probably the most far-reaching proposal goes under the snappy name of "Minimal Support for Garbage Collection and Reachability-Based Leak Detection". First up, this does not mean C++0x just became a garbage collected language! However, this carefully crafted proposal inserts just enough requirements into the memory model to make a GC implementation practical and reasonable, so while GC is not a required feature we should expect to see garbage collected implementations in the future, although I expect many will come with a compiler switch to enable or disable the feature. The cost of this feature is that some currently valid programs will find they rely on undefined behaviour in C++0x. Generally, unless the GC switch is thrown, that undefined behaviour will continue to do exactly what it does today, so I expect few programs will break out-of-the-box.
To enable GC two new ways of describing pointer values have been defined. A safely derived pointer is what you get from calling a memory allocation routine such as malloc or new, or a copy of such a pointer. A reconstituted pointer is what you get when you start playing tricks with the value, such as using bitmasks or storing it in an integer variable. When you restore the pointer value it is now reconstituted and it is no longer guaranteed to be safe to deference such a pointer. This is the freedom that allows a garbage collector to reclaim memory. If this kind of behaviour is important to your program (and there are various well-documented idioms using these techniques, not least storing pointers in the Tag property of VCL components!) then you can call a new library function declare_reachable before ‘hiding’ your pointer. Reconstituted pointers to an object previously declared as reachable can be safely deferenced, until after a later call to declare_unreachable. This effectively gives us a way to tell the garbage collector about hidden pointers, so it does not collect too early. This nice thing about this formulation in terms of reconstituted pointers is that it is not specific to garbage collection. I am curious to see what other interesting applications turn up such as improved memory-leak detection tools.
Next time I will talk more about library support for concurrency.
Posted by Alisdair Meredith in C++0x | RSS 2.0
Leave a Reply
You must be logged in to post a comment.