ISO/IEC JTC1 SC22 WG21 N3074 = 10-0064 - 2010-03-11
Paul E. McKenney, paulmck@linux.vnet.ibm.com
Mark Batty, mjb220@cl.cam.ac.uk
Clark Nelson, clark.nelson@intel.com
N.M. Maclaren, nmm1@cam.ac.uk
Hans Boehm, hans.boehm@hp.com
Anthony Williams, anthony@justsoftwaresolutions.co.uk
Peter Dimov, pdimov@mmltd.net
Lawrence Crowl, crowl@google.com, Lawrence@Crowl.org
Mark Batty recently undertook a partial formalization of the C++ memory model, which Mark summarized in N2955. This paper summarizes the discussions on Mark's paper, both verbal and email, recommending appropriate actions for the Core Working Group. Library issues are dealt with in a separate N3057 paper.
This paper is based on N3045, and has been updated to reflect discussions in the Concurrency subgroup of the Library Working Group in Pittsburgh. This paper also carries the C-language side of N3040, which was also discussed in the Concurrency subgroup of the Library Working Group in Pittsburgh.
The phrase “might be” is indefinite and should be reworded.
Replace “might be” with “is”:
N2955 suggests two changes to 1.10p14:
Recommendation: no change.
memory_order_seq_cst
operations are also used outside
of lock-based critical sections, the result is still simple
interleaving.
If atomic memory_order_seq_cst
operations are also used both
inside and outside of lock-based critical sections, the
result is still sequentially consistent, but the individual
lock-based critical sections are no longer simply interleaved.
However, the result will be consistent with at least one simple
interleaving of
the individual operations making up each critical section.
Recommendation: update note to include atomic
memory_order_seq_cst
, reworking the wording
appropriately.
Atomic and locking objects are not trivially copyable [29.5.1p2, 29.5.2p1,
29.5.3p2], so the result of copying them (for example,
via std::memcpy
)
are not specified by the standard [3.9].
Additionally, if the memcpy
operation results in a data race, then undefined behavior is explicitly
specified by the working draft [1.10p14].
There was some spirited discussion of the non-data-race case on the email reflector, with the following positions outlined:
memory_order_relaxed
,
and that there are a number of
situations (including some implementations of resizeable
hash tables) where most accesses to a given object are not
subject to data races.
In such cases, there is good reason to avoid
memory_order_relaxed
's
overhead for accesses known to be data-race free.
memcpy
)
was at best unspecified, at worst undefined.
memory_order_relaxed
load, so
it is not necessary to define the effect of copying the
underlying representation.
Furthermore, the effect of copying an underlying representation
to an atomic object can be both safely and efficiently emulated
via a memory_order_relaxed
store for machine-word-sized
accesses, which are the most common in practice.
memory_order
enum
member that would permit the implementation to access the
atomic object non-atomically (for the purposes of this paper,
call it memory_order_nonatomic
).
This could be thought of as specifying memory ordering that is
so relaxed that the implementation need not even guarantee
indivisibility of different accesses to the same
atomic object.
A memory_order_nonatomic
operation would therefore be subject
to data races.
Therefore, this paper recommends no changes to 1.10p4.
This paper does not recommend adding memory_order_nonatomic
to c++0x, but something similar should be considered for a later TR
or a later version of the standard.
The phrase “M is a maximal contiguous” could be interpreted as meaning the sequence having the maximum value or any of a number of alternative interpretations. However, there were other instances of this abbreviation that were not objected to, so recommend no change.
The intent of this paragraph is that initialization be considered a separate access, but this is not explicitly stated. There is some debate as to whether this needs to be explicitly stated. In absence of consensus, let those who read the words of this paragraph apply appropriate common sense.
As with 1.10p12, the intent of this paragraph is that initialization be considered a separate access, but this is not explicitly stated. There is some debate as to whether this needs to be explicitly stated. In absence of consensus, let those who read the words of this paragraph apply appropriate common sense.
This section lists WG21 C++-language wording. The corresponding WG14 C-language wording is shown in a separate section to ease coordination of changes to the two working drafts.
Reword the 1.10p2 as follows:
The value of an object visible to a thread T at a particular point
might beis the initial value of the object, a value assigned to the object by T , or a value assigned to the object by another thread, according to the rules below. [ Note: In some cases, there may instead be undefined behavior. Much of this section is motivated by the desire to support atomic operations with explicit and detailed visibility constraints. However, it also implicitly supports a simpler view for more restricted programs. — end note ]
Reword the non–normative note in 1.10p14 to include sequentially consistent atomic operations as well as lock–based critical sections, as follows:
The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. [ Note: It can be shown that programs that correctly use simple locks and
memory_order_seq_cst
operations to prevent all data races and that use no other synchronization operations behave asthe executions ofif the operations executed by their constituent threadswereare simply interleaved, with eachobserved valuevalue computation of an object being thelast value assignedlast side effect on that object in that interleaving. This is normally referred to as “sequential consistency”. However, this applies only to data–race–free programs, and data–race–free programs cannot observe most program transformations that do not change single–threaded program semantics. In fact, most single–threaded program transformations continue to be allowed, since any program that behaves differently as a result must perform an undefined operation. — end note ]
Change WG14 5.1.2.4p2 as follows:
The value of an object visible to a thread T at a particular point
might beis the initial value of the object, a value assigned to the object by T , or a value assigned to the object by another thread, according to the rules below.
Change WG14 5.1.2.4p23 as follows:
NOTE 11 It can be shown that programs that correctly use simple locks and
memory_order_seq_cst
operations to prevent all data races,that and use no other synchronization operations,behave as thoughthe executions ofthe operations executed by their constituent threadswereare simply interleaved, with eachobserved valuevalue computation of an object being thelast value assignedlast side effect on that object in that interleaving. This is normally referred to as “sequential consistency”. However, this applies only to data-race-free programs, and data-race-free programs cannot observe most program transformations that do not change single-threaded program semantics. In fact, most single-threaded program transformations continue to be allowed, since any program that behaves differently as a result must contain undefined behavior.