Стандарт C++ 11, страница 9

The first exceptionis that a concatenation is not permitted to end with “dependency-ordered before” followed by “sequencedbefore”. The reason for this limitation is that a consume operation participating in a “dependency-orderedbefore” relationship provides ordering only with respect to operations to which this consume operationactually carries a dependency. The reason that this limitation applies only to the end of such a concatenationis that any subsequent release operation will provide the required ordering for a prior consume operation.The second exception is that a concatenation is not permitted to consist entirely of “sequenced before”.The reasons for this limitation are (1) to permit “inter-thread happens before” to be transitively closed and(2) the “happens before” relation, defined below, provides for relationships consisting entirely of “sequencedbefore”.

— end note ]12An evaluation A happens before an evaluation B if:— A is sequenced before B, or— A inter-thread happens before B.The implementation shall ensure that no program execution demonstrates a cycle in the “happens before”relation. [ Note: This cycle would otherwise be possible only through the use of consume operations. — endnote ]13A visible side effect A on a scalar object or bit-field M with respect to a value computation B of M satisfiesthe conditions:— A happens before B and— there is no other side effect X to M such that A happens before X and X happens before B.The value of a non-atomic scalar object or bit-field M , as determined by evaluation B, shall be the valuestored by the visible side effect A.

[ Note: If there is ambiguity about which side effect to a non-atomic objector bit-field is visible, then the behavior is either unspecified or undefined. — end note ] [ Note: This statesthat operations on ordinary objects are not visibly reordered. This is not actually detectable without dataraces, but it is necessary to ensure that data races, as defined below, and with suitable restrictions on theuse of atomics, correspond to data races in a simple interleaved (sequentially consistent) execution.

— endnote ]14The visible sequence of side effects on an atomic object M , with respect to a value computation B of M , isa maximal contiguous sub-sequence of side effects in the modification order of M , where the first side effectis visible with respect to B, and for every side effect, it is not the case that B happens before it. The valueof an atomic object M , as determined by evaluation B, shall be the value stored by some operation in thevisible sequence of M with respect to B.

[ Note: It can be shown that the visible sequence of side effects ofa value computation is unique given the coherence requirements below. — end note ]15If an operation A that modifies an atomic object M happens before an operation B that modifies M , thenA shall be earlier than B in the modification order of M . [ Note: This requirement is known as write-writecoherence. — end note ]16If a value computation A of an atomic object M happens before a value computation B of M , and A takesits value from a side effect X on M , then the value computed by B shall either be the value stored by X orthe value stored by a side effect Y on M , where Y follows X in the modification order of M . [ Note: Thisrequirement is known as read-read coherence.

— end note ]17If a value computation A of an atomic object M happens before an operation B on M , then A shall takeits value from a side effect X on M , where X precedes B in the modification order of M . [ Note: Thisrequirement is known as read-write coherence. — end note ]§ 1.1014© ISO/IEC 2011 – All rights reservedISO/IEC 14882:2011(E)18If a side effect X on an atomic object M happens before a value computation B of M , then the evaluationB shall take its value from X or from a side effect Y that follows X in the modification order of M . [ Note:This requirement is known as write-read coherence. — end note ]19[ Note: The four preceding coherence requirements effectively disallow compiler reordering of atomic operations to a single object, even if both operations are relaxed loads.

This effectively makes the cache coherenceguarantee provided by most hardware available to C++ atomic operations. — end note ]20[ Note: The visible sequence of side effects depends on the “happens before” relation, which depends on thevalues observed by loads of atomics, which we are restricting here. The intended reading is that there mustexist an association of atomic loads with modifications they observe that, together with suitably chosenmodification orders and the “happens before” relation derived as described above, satisfy the resultingconstraints as imposed here. — end note ]21The 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 inundefined behavior.

[ Note: It can be shown that programs that correctly use mutexes and memory_order_seq_cst operations to prevent all data races and use no other synchronization operations behave as if theoperations executed by their constituent threads were simply interleaved, with each value computation of anobject being taken from the last 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 programscannot observe most program transformations that do not change single-threaded program semantics. Infact, most single-threaded program transformations continue to be allowed, since any program that behavesdifferently as a result must perform an undefined operation.

— end note ]22[ Note: Compiler transformations that introduce assignments to a potentially shared memory location thatwould not be modified by the abstract machine are generally precluded by this standard, since such anassignment might overwrite another assignment by a different thread in cases in which an abstract machineexecution would not have encountered a data race. This includes implementations of data member assignment that overwrite adjacent members in separate memory locations.

Reordering of atomic loads in casesin which the atomics in question may alias is also generally precluded, since this may violate the “visiblesequence” rules. — end note ]23[ Note: Transformations that introduce a speculative read of a potentially shared memory location may notpreserve the semantics of the C++ program as defined in this standard, since they potentially introduce adata race. However, they are typically valid in the context of an optimizing compiler that targets a specificmachine with well-defined semantics for data races.

They would be invalid for a hypothetical machine thatis not tolerant of races or provides hardware race detection. — end note ]24The implementation may assume that any thread will eventually do one of the following:— terminate,— make a call to a library I/O function,— access or modify a volatile object, or— perform a synchronization operation or an atomic operation.[ Note: This is intended to allow compiler transformations such as removal of empty loops, even whentermination cannot be proven. — end note ]25An implementation should ensure that the last value (in modification order) assigned by an atomic orsynchronization operation will become visible to all other threads in a finite period of time.§ 1.10© ISO/IEC 2011 – All rights reserved15ISO/IEC 14882:2011(E)1.11Acknowledgments[intro.ack]1The C++ programming language as described in this International Standard is based on the language asdescribed in Chapter R (Reference Manual) of Stroustrup: The C++ Programming Language (second edition,cAT&T).

That, in turn, is basedAddison-Wesley Publishing Company, ISBN 0-201-53992-6, copyright 1991on the C programming language as described in Appendix A of Kernighan and Ritchie: The C ProgrammingcLanguage (Prentice-Hall, 1978, ISBN 0-13-110163-3, copyright 1978AT&T).2Portions of the library Clauses of this International Standard are based on work by P.J. Plauger, which wascpublished as The Draft Standard C++ Library (Prentice-Hall, ISBN 0-13-117003-1, copyright 1995P.J.Plauger).3R is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc.POSIX4All rights in these originals are reserved.§ 1.1116© ISO/IEC 2011 – All rights reservedISO/IEC 14882:2011(E)2Lexical conventions2.1Separate translation[lex][lex.separate]1The text of the program is kept in units called source files in this International Standard.

A source filetogether with all the headers (17.6.1.2) and source files included (16.2) via the preprocessing directive#include, less any source lines skipped by any of the conditional inclusion (16.1) preprocessing directives, iscalled a translation unit. [ Note: A C++ program need not all be translated at the same time. — end note ]2[ Note: Previously translated translation units and instantiation units can be preserved individually or inlibraries.