New technology in the C++ language enables a higher degree of interaction and compatibility between C and C++. The draft paper is available on the WG14 Wiki.
This technology is embodied in the atomic types proposal, which includes interfaces that enable simultaneous and compatible use of atomic types by both C and C++ translation units. The paper shows a unified C and C++ implementation.
This technology is not embodied in thread library proposal. The C++ committee chose not to define those interfaces, though early implementations of those works did have such interfaces. The core requirement necessary for full interaction, that the thread-related types be standard-layout, is still present in the proposal. We believe that the C committee can define suitable interfaces and remain compatible.
The C++ proposal WG21 N2427 C++ Atomic Types and Operations has been adopted into the working draft for the next C++ standard.
The interface consists of
The following issues are of particular note.
This interface includes generally two forms of each 'function', one for sequentially consistent execution and one for explicit specification of the consistency. For example,
void atomic_store( volatile atomic_int*, int ); void atomic_store_explicit( volatile atomic_int*, int, memory_order );
In C++, this would naturally be written as a single function with a default final argument. In C, though, these 'functions' would be type generic macros and there is no precedence in the standard for them. There is a precedence in the Intel/Gnu __sync macros. The specification and use would be easier with a single function with an optional final argument. That is, allowing both:
atomic_store( &av, 3 ); atomic_store( &av, 3, memory_order_relaxed );
We believe it would be reasonable to add operators for atomic integral types in C. The resulting syntax would be much easier to use.
A hardware compare-and-swap operation compares whole bytes or words,
so atomic types must be bitwise equality-comparable,
i.e., must have no garbage bits.
If we want to have atomic booleans, which seems reasonable,
implementations must normalize boolean values to 0 and 1
before storing values in
In normal C++ execution, destructors for static-duration variables are called as a result of calling exit. In a multi-threaded program, this behavior causes risk of destroying a variable in one thread while another thread is accessing that variable, yielding undefined behavior.
Calling _Exit is also not reasonable because it provides no mechanism to write critical data out of the process. C++ needs a facility intermediate between exit and _Exit.
WG21 N2440 Abandoning a Process proposes function at_quick_exit to register functions and function quick_exit to call those functions and then call _Exit.
The effect on existing code is that users would have to add an at_quick_exit call after many atexit that they have now. They may also need to add at_quick_exit calls to flush file buffers.
WG21 N2440 Abandoning a Process has been adopted into the working draft for the next C++ standard.
The C++ library proposal WG21 N2447 Multi-threading Library for Standard C++ includes types for threads, mutexes, and condition variables. In addition, it defines types for specifying time in timed waits. The proposal has general consensus and is working towards final wording.
Most notably the proposal excludes facilities for cancellation (AKA interruption), thus removing a very contentious issue and a potentially difficult C and C++ interaction problem.
The paper WG21 N2444 Dynamic Initialization and Destruction with Concurrency handles issues unique to C++, but has an algorithm of interest for synchronized initialization in, for example, pthread_once.
The paper WG21 N2410 Thread-Safety in the Standard Library (Rev 1) discusses issues of thread-safety that may be relevant in general to the C committee.