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

[ Note: Valuecomputations and side effects associated with different argument expressions are unsequenced. — end note ]Every evaluation in the calling function (including other function calls) that is not otherwise specificallysequenced before or after the execution of the body of the called function is indeterminately sequenced withrespect to the execution of the called function.9 Several contexts in C++ cause evaluation of a function call,even though no corresponding function call syntax appears in the translation unit. [ Example: Evaluation ofa new expression invokes one or more allocation and constructor functions; see 5.3.4.

For another example,invocation of a conversion function (12.3.2) can arise in contexts in which no function call syntax appears.— end example ] The sequencing constraints on the execution of the called function (as described above)are features of the function calls as evaluated, whatever the syntax of the expression that calls the functionmight be.8) As specified in 12.2, after a full-expression is evaluated, a sequence of zero or more invocations of destructor functions fortemporary objects takes place, usually in reverse order of the construction of each temporary object.9) In other words, function executions do not interleave with each other.§ 1.9© ISO/IEC 2011 – All rights reserved11ISO/IEC 14882:2011(E)1.10Multi-threaded executions and data races[intro.multithread]1A thread of execution (also known as a thread) is a single flow of control within a program, including the initialinvocation of a specific top-level function, and recursively including every function invocation subsequentlyexecuted by the thread.

[ Note: When one thread creates another, the initial call to the top-level function ofthe new thread is executed by the new thread, not by the creating thread. — end note ] Every thread in aprogram can potentially access every object and function in a program.10 Under a hosted implementation, aC++ program can have more than one thread running concurrently. The execution of each thread proceedsas defined by the remainder of this standard. The execution of the entire program consists of an execution ofall of its threads. [ Note: Usually the execution can be viewed as an interleaving of all its threads.

However,some kinds of atomic operations, for example, allow executions inconsistent with a simple interleaving, asdescribed below. — end note ] Under a freestanding implementation, it is implementation-defined whethera program can have more than one thread of execution.2Implementations should ensure that all unblocked threads eventually make progress. [ Note: Standardlibrary functions may silently block on I/O or locks. Factors in the execution environment, includingexternally-imposed thread priorities, may prevent an implementation from making certain guarantees offorward progress. — end note ]3The value of an object visible to a thread T at a particular point is the initial value of the object, a valueassigned to the object by T , or a value assigned to the object by another thread, according to the rulesbelow.

[ Note: In some cases, there may instead be undefined behavior. Much of this section is motivatedby the desire to support atomic operations with explicit and detailed visibility constraints. However, it alsoimplicitly supports a simpler view for more restricted programs. — end note ]4Two expression evaluations conflict if one of them modifies a memory location (1.7) and the other oneaccesses or modifies the same memory location.5The library defines a number of atomic operations (Clause 29) and operations on mutexes (Clause 30)that are specially identified as synchronization operations. These operations play a special role in makingassignments in one thread visible to another. A synchronization operation on one or more memory locationsis either a consume operation, an acquire operation, a release operation, or both an acquire and releaseoperation.

A synchronization operation without an associated memory location is a fence and can be eitheran acquire fence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomicoperations, which are not synchronization operations, and atomic read-modify-write operations, which havespecial characteristics. [ Note: For example, a call that acquires a mutex will perform an acquire operationon the locations comprising the mutex.

Correspondingly, a call that releases the same mutex will perform arelease operation on those same locations. Informally, performing a release operation on A forces prior sideeffects on other memory locations to become visible to other threads that later perform a consume or anacquire operation on A. “Relaxed” atomic operations are not synchronization operations even though, likesynchronization operations, they cannot contribute to data races. — end note ]6All modifications to a particular atomic object M occur in some particular total order, called the modificationorder of M .

If A and B are modifications of an atomic object M and A happens before (as defined below) B,then A shall precede B in the modification order of M , which is defined below. [ Note: This states that themodification orders must respect the “happens before” relationship. — end note ] [ Note: There is a separateorder for each atomic object.

There is no requirement that these can be combined into a single total order forall objects. In general this will be impossible since different threads may observe modifications to differentobjects in inconsistent orders. — end note ]10) An object with automatic or thread storage duration (3.7) is associated with one specific thread, and can be accessed bya different thread only indirectly through a pointer or reference (3.9.2).§ 1.1012© ISO/IEC 2011 – All rights reservedISO/IEC 14882:2011(E)7A release sequence headed by a release operation A on an atomic object M is a maximal contiguous subsequence of side effects in the modification order of M , where the first operation is A, and every subsequentoperation— is performed by the same thread that performed A, or— is an atomic read-modify-write operation.8Certain library calls synchronize with other library calls performed by another thread.

For example, anatomic store-release synchronizes with a load-acquire that takes its value from the store (29.3). [ Note:Except in the specified cases, reading a later value does not necessarily ensure visibility as described below.Such a requirement would sometimes interfere with efficient implementation. — end note ] [ Note: Thespecifications of the synchronization operations define when one reads the value written by another. Foratomic objects, the definition is clear. All operations on a given mutex occur in a single total order. Eachmutex acquisition “reads the value written” by the last mutex release. — end note ]9An evaluation A carries a dependency to an evaluation B if— the value of A is used as an operand of B, unless:— B is an invocation of any specialization of std::kill_dependency (29.3), or— A is the left operand of a built-in logical AND (&&, see 5.14) or logical OR (||, see 5.15) operator,or— A is the left operand of a conditional (?:, see 5.16) operator, or— A is the left operand of the built-in comma (,) operator (5.18);or— A writes a scalar object or bit-field M , B reads the value written by A from M , and A is sequencedbefore B, or— for some evaluation X , A carries a dependency to X , and X carries a dependency to B.[ Note: “Carries a dependency to” is a subset of “is sequenced before”, and is similarly strictly intra-thread.— end note ]10An evaluation A is dependency-ordered before an evaluation B if— A performs a release operation on an atomic object M , and, in another thread, B performs a consumeoperation on M and reads a value written by any side effect in the release sequence headed by A, or— for some evaluation X , A is dependency-ordered before X and X carries a dependency to B.[ Note: The relation “is dependency-ordered before” is analogous to “synchronizes with”, but uses release/consume in place of release/acquire.

— end note ]11An evaluation A inter-thread happens before an evaluation B if— A synchronizes with B, or— A is dependency-ordered before B, or— for some evaluation X— A synchronizes with X and X is sequenced before B, or— A is sequenced before X and X inter-thread happens before B, or— A inter-thread happens before X and X inter-thread happens before B.§ 1.10© ISO/IEC 2011 – All rights reserved13ISO/IEC 14882:2011(E)[ Note: The “inter-thread happens before” relation describes arbitrary concatenations of “sequenced before”,“synchronizes with” and “dependency-ordered before” relationships, with two exceptions.