October 23-27 meeting of ISO SC22 WG14, the C programming language committee (Part 1 of 3)
By C Project Lead on Nov 03, 2006
- Lawrence Crowl of Google gave a presentation on where C++ threads is going.
- A proposal for Sequence Points work for the C rationale. This is in response to C++ threads work in understanding sequence points.
- Proposal to augment the interface of malloc, et al.
- DTR 24732, Decimal Floating Point headed for final balloting after some minor updates.
- DR review
- TR24731, Part II, Bounds Checking via dynamic allocation.
- We also had a visitor this meeting, Ulrich Drepper from Red Hat, Ulrich talked about his perceptions of the future of C. This lead to the main surprise of this meeting, committee sentiment to consider opening the C standard for another revision.
Here are the details on what Lawrence Crowl presented on where C++ threads is going ...
Lawrence Crowl gave a presentation on where C++ threads is going. C++ is trying to make threads correspond to operating system threads, POSIX and Windows, but not cover all of the functionality. They will be heavyweight, preemptive, and independent. Not a replacement for existing Standards. Presuming that all writes are available to all threads is not viable, and C++ wants to adopt a message memory model.
Sequencing has been redefined. Sequence points are gone. Relations are sequenced-before and indeterminately-sequenced. A write-to and read-from a location that are not sequence-before and not indeterminately-sequenced results in undefined behavior.
The sequence rules have been extended to concurrency. Relations are synchronizes-with and happens-before are based on acquire and release. Race conditions are defined. The existence of a race condition makes the program undefined.
A location is a non-bitfield primitive data object. Adjacent bitfields together constitute a single location, enables unsynchronized read-modify-write.
The C++ Committee decided there needs to be some compromised between the language and the hardware. Ulrich has an opinion that needs to be communicated back to WG21 via liaison. He has been talking with Hans Boehm in WG21 about this and prefers to have the POSIX type binding for threads (pthreads).
Optimizers are affected. Some speculative writes and reads are no longer legal. Loops without synchronization may be assumed to terminate.
All threads observe the same sequence of values for an atomic type. Atomic operations acquire, release, both, and neither. Atomic types are struct, but could be primitive type. Operators are type generic macros in C. The default assignment operator for both C and C++ is wrong, and cannot be disable in C99. It can be disable in C++98, but doing so breaks C/C++ compatibility. C++ has a template for making any type atomic.
The types are comprehensive over the important primitive types: atomic_flag, atomic_bool, atomic_integers, atomic_void_pointer. Atomics may be compiled by both C and C++. Atomic operations must be lock-free to be used in signals. A macro will indicate if a type is lock-fee. Atomic operations must be address-free if used between processes. If an operation is lock-free , it must also be address-free. Sequential consistency is not settled, and can be affected by hardware design. Example: How to program 'total store order'. Experts doubt whether mortals can program effectively without a total store order.
Thread-local storage has been implemented by at least five vendors. Some have slightly different syntax. A new thread duration has been defined. Dynamic initialization and destruction of static-duration variables can be tricky. Without implicit synchronization, there is the potential for data races. With implicit synchronization, there is the potential for deadlock.
The thread semantic model initiates a thread with a fork on a function call (semantically like pthreads). Join waits for the function to return. Some open questions remain. Is there a test for ready for join? Is there a join with a timeout? Does join return a function value?
Mutexes provide mutual exclusion. The Standard (C++) will have a least a simple mutex, and may have read-write and reentrant mutexes. Conditional variables enable the monitor paradigm. Threads may wait on a conditional variable.
Thread termination is voluntary. Return form outermost function, likely to have some form of cooperative termination, possible have some for of synchronous cancellation (exists in Windows) and there is strong opposition to asynchronous cancellation. Thread scheduling is limited.
Locks hold a mutex within a given scope.
Higher level primitives may be built on primitives such as tread pools, thread groups, parallel iterators, etc.
Further threads work is being prepared for inclusion in C++ TR2, which will follow the next revision of C++ scheduled for 2009.
I'll cover the other topics in some future postings