ISO/IEC9899:2011 (E)ISO/IEC2011-Allrights reserved5The library defines a number of atomic operations (7.17)and operations on mutexes(7.26.4) that are specially identified as synchronization operations. These operations playa special role in making assignments in one thread visible to another. A synchronizationoperation on one or more memory locations is either an acquire operation, a releaseoperation, both an acquire and release operation, or a consume operation. Asynchronization operation without an associated memory location is a fence and can beeitheranacquirefence,areleasefence,orbothanacquireandreleasefence.Inadditionthere are relaxed atomic operations, which are not synchronization operations, andatomic read-modify-write operations,whichhave special characteristics.NOTE2For example,a call that acquires a mutex will perform an acquire operation on the locations6composing the mutex.Correspondingly, a call that releases the same mutex will perform a releaseoperationonthosesamelocations.Informally,performingareleaseoperationonAforcespriorsideeffectson other memory locations to becomevisibletootherthreads thatlater perform an acquireor consumeoperation on A.Wedonot includerelaxed atomic operationsas synchronization operations although,likesynchronizationoperations,they cannotcontributetodata races.All modifications to a particular atomic object M occur in some particular total order,7called the modification order of M.If AandB aremodifications of anatomic object Mand A happens before B, then A shall precede B in the modification order of M, which isdefined below.NOTE3This states that the modification orders must respect the“happens before"relation.8NOTE4There is a separate order for each atomic object.There is no requirement that these can be9combined into a single total order for all objects. In general this will be impossible since different threadsmay observe modificationsto different variables in inconsistentorders.10A release sequence headed by a release operation A on an atomic object M is a maximalcontiguous sub-sequence of side effects in the modification order of M, where the firstoperation is A and every subsequent operation either is performed by the same thread thatperformed the release or is an atomic read-modify-write operation.11Certain library calls synchronize with other library calls performed by another thread. Inparticular, an atomic operation A that performs a release operation on an object Msynchronizes with an atomic operationB that performs an acquire operation on M andreads a value written by any side effect in the release sequence headed by A.NOTE5Except in the specified cases,reading a later value does not necessarily ensure visibility as12described below. Such a requirement would sometimes interfere with efficient implementation.NOTE6The specifications of the synchronization operationsdefine when one reads the value written by13another.For atomic variables, the definition is clear.All operations on a given mutex occur in a single totalorder.Eachmutex acquisition“reads the valuewrittenby thelast mutex release.14An evaluation A carries a dependency15) to an evaluation B if:15)The “carries a dependency" relation is a subset of the“"sequenced before"relation, and is similarlystrictly intra-thread.18Environment$5.1.2.4
ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved 5 The library defines a number of atomic operations (7.17) and operations on mutexes (7.26.4) that are specially identified as synchronization operations. These operations play a special role in making assignments in one thread visible to another. A synchronization operation on one or more memory locations is either an acquire operation, a release operation, both an acquire and release operation, or a consume operation. A synchronization operation without an associated memory location is a fence and can be either an acquire fence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomic operations, which are not synchronization operations, and atomic read-modify-write operations, which have special characteristics. 6 NOTE 2 For example, a call that acquires a mutex will perform an acquire operation on the locations composing the mutex. Correspondingly, a call that releases the same mutex will perform a release operation on those same locations. Informally, performing a release operation on A forces prior side effects on other memory locations to become visible to other threads that later perform an acquire or consume operation on A. We do not include relaxed atomic operations as synchronization operations although, like synchronization operations, they cannot contribute to data races. 7 All modifications to a particular atomic object M occur in some particular total order, called the modification order of M. If A and B are modifications of an atomic object M, and A happens before B, then A shall precede B in the modification order of M, which is defined below. 8 NOTE 3 This states that the modification orders must respect the ‘‘happens before’’ relation. 9 NOTE 4 There is a separate order for each atomic object. There is no requirement that these can be combined into a single total order for all objects. In general this will be impossible since different threads may observe modifications to different variables in inconsistent orders. 10 A release sequence headed by a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A and every subsequent operation either is performed by the same thread that performed the release or is an atomic read-modify-write operation. 11 Certain library calls synchronize with other library calls performed by another thread. In particular, an atomic operation A that performs a release operation on an object M synchronizes with an atomic operation B that performs an acquire operation on M and reads a value written by any side effect in the release sequence headed by A. 12 NOTE 5 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. 13 NOTE 6 The specifications of the synchronization operations define when one reads the value written by another. For atomic variables, the definition is clear. All operations on a given mutex occur in a single total order. Each mutex acquisition ‘‘reads the value written’’ by the last mutex release. 14 An evaluation A carries a dependency15) to an evaluation B if: 15) The ‘‘carries a dependency’’ relation is a subset of the ‘‘sequenced before’’ relation, and is similarly strictly intra-thread. 18 Environment §5.1.2.4
ISO/IEC 2011 - All rights reservedISO/IEC9899:2011 (E)- the value of A is used as an operand of B, unless:.Bisaninvocationofthekiil dependencymacro,.Aistheleft operand ofa&&orI Ioperator,·A is theleft operand of a?:operator,or.Ais theleft operand ofa,operator,orA writes a scalar object or bit-field M, B reads from M the value written by A, and Ais sequenced before B, orfor some evaluation X, A carriesa dependency to X and X carries a dependencytoB15An evaluation A is dependency-ordered before16) an evaluation B if.A performs a release operation on an atomic object M, and, in another thread, Bperforms a consume operation on M and reads a value written by any side effect intherelease sequenceheadedbyA, orforsomeevaluationX,A is dependency-orderedbefore Xand X carries adependency to B.16AnevaluationAinter-threadhappens beforean evaluationBif AsynchronizeswithB,Ais dependency-ordered before B, or, for some evaluation X:-A synchronizes with X and X is sequenced before B,A is sequenced before X and X inter-thread happens before B, or-Ainter-thread happensbeforeXand X inter-thread happens beforeB.NOTE7The"inter-thread happens before"relation describes arbitrary concatenations of“"sequenced17before",“synchronizeswith",and“"dependency-ordered before"relationships,withtwoexceptions.Thefirstexception isthat a concatenation is notpermitted to end with"dependency-ordered before"followedby “sequenced beforeThe reason for this limitation is that a consume operation participating in a"dependency-ordered before"relationship provides ordering only with respect to operations to which thisconsume operation actually carries a dependency.The reason that this limitation applies only to theend ofsuch a concatenation is that any subsequent release operation will provide the required ordering for a priorconsumeoperation.Thesecond exception is that a concatenation is notpermitted to consist entirely of"sequenced before"Thereasonsforthis limitation are(l)to permitinter-thread happens before"to betransitively closed and(2)thehappens before"relation,defined below, provides for relationshipsconsisting entirely of"sequenced before"18AnevaluationAhappensbeforeanevaluationBif Ais sequencedbeforeBorAinter-thread happens before B.16)Thedependency-ordered before"relation is analogousto the“synchronizes with"relation,butusesrelease/consumeinplaceofrelease/acquire19$5.1.2.4Environment
© ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E) — the value of A is used as an operand of B, unless: • B is an invocation of the kill_dependency macro, • A is the left operand of a && or || operator, • A is the left operand of a ? : operator, or • A is the left operand of a , operator; or — A writes a scalar object or bit-field M, B reads from M the value written by A, and A is sequenced before B, or — for some evaluation X, A carries a dependency to X and X carries a dependency to B. 15 An evaluation A is dependency-ordered before16) an evaluation B if: — A performs a release operation on an atomic object M, and, in another thread, B performs a consume operation 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. 16 An evaluation A inter-thread happens before an evaluation B if A synchronizes with B, A is dependency-ordered before B, or, for some evaluation X: — A synchronizes with X and X is sequenced before B, — 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. 17 NOTE 7 The ‘‘inter-thread happens before’’ relation describes arbitrary concatenations of ‘‘sequenced before’’, ‘‘synchronizes with’’, and ‘‘dependency-ordered before’’ relationships, with two exceptions. The first exception is that a concatenation is not permitted to end with ‘‘dependency-ordered before’’ followed by ‘‘sequenced before’’. The reason for this limitation is that a consume operation participating in a ‘‘dependency-ordered before’’ relationship provides ordering only with respect to operations to which this consume operation actually carries a dependency. The reason that this limitation applies only to the end of such a concatenation is 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 ‘‘sequenced before’’. 18 An evaluation A happens before an evaluation B if A is sequenced before B or A interthread happens before B. 16) The ‘‘dependency-ordered before’’ relation is analogous to the ‘‘synchronizes with’’ relation, but uses release/consume in place of release/acquire. §5.1.2.4 Environment 19
ISO/IEC9899:2011 (E)ISO/IEC 2011 -All rights reserved19A visible side effect A on an object M with respect to a value computation B of Msatisfiesthe conditions:AhappensbeforeB,andthere is no other side effect X to M such that A happens before X and X happensbeforeB.The value of a non-atomic scalar object M, as determined by evaluation B, shall be thevaluestoredbythevisiblesideeffectANOTE 8If there is ambiguity about which side effect to a non-atomic object is visible, then there is a data20race and the behavior is undefined.NOTE 9This states that operations on ordinary variables are not visibly reordered.This is not actually21detectablewithoutdata races,but it is necessarytoensurethat dataraces, asdefinedhere,and withsuitablerestrictions on the use of atomics,correspond to data races in a simple interleaved (sequentiallyconsistent)execution.22The visible sequenceof sideeffects on an atomic object M,with respect toa valuecomputation B of M,isa maximal contiguous sub-sequence of side effects in themodificationorderofM,wherethefirstsideeffectisvisiblewithrespecttoB,andforevery subsequent side effect, it isnot the case that Bhappens before it.Thevalue of anatomicobjectM,asdeterminedbyevaluationB,shallbethevalue stored bysomeoperation in the visible sequenceof M with respecttoB.Furthermore,if a valuecomputation A of an atomic object M happens before a value computation B of M, andthe value computed by A corresponds to the value stored by side effect X, then thevaluecomputedbyBshalleitheregualthevaluecomputedbyA,orbethevaluestoredbysideeffectY.whereYfollowsXinthemodificationorderofMNOTE10This effectively disallows compiler reordering of atomic operations to a single object, even if23both operations are "relaxed" loads.By doing so, we effectively make the “cache coherence"guaranteeprovidedbymosthardwareavailabletoCatomicoperations.NOTE1lThevisible sequencedepends on the“happens beforerelation,which in turn depends on the24values observed by loads of atomics, which we are restricting here.The intended reading is that there mustexistanassociation of atomic loads withmodifications theyobservethat,togetherwithsuitablychosenmodification orders and the"happens before""relation derived as described above, satisfy the resultingconstraintsas imposedhere.25Theexecutionofaprogramcontainsadataraceifitcontainstwoconflictingactionsindifferent threads, at least one of which is not atomic, and neither happens before theother.Any such data race results in undefined behavior.NOTE12Itcanbeshownthatprogramsthatcorrectlyusesimplemutexesand26memory_orderseg_cst operationsto prevent alldata races,anduse no other synchronizationoperations, behave as though the operations executed by their constituent threads were simply interleavedwith eachvalue computation of anobject being the last value stored in that interleaving.This is normallyreferred toas"sequential consistency"However, this applies only to data-race-freeprograms, and data-race-free programs cannot observemost programtransformations thatdo not change single-threadedprogram semantics.Infact, most single-threadedprogramtransformations continueto beallowed,sinceanyprogram thatbehaves differentlyas a result mustcontainundefined behavior.20$5.1.2.4Environment
ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved 19 A visible side effect A on an object M with respect to a value computation B of M satisfies the 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 M, as determined by evaluation B, shall be the value stored by the visible side effect A. 20 NOTE 8 If there is ambiguity about which side effect to a non-atomic object is visible, then there is a data race and the behavior is undefined. 21 NOTE 9 This states that operations on ordinary variables are not visibly reordered. This is not actually detectable without data races, but it is necessary to ensure that data races, as defined here, and with suitable restrictions on the use of atomics, correspond to data races in a simple interleaved (sequentially consistent) execution. 22 The visible sequence of side effects on an atomic object M, with respect to a value computation B of M, is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first side effect is visible with respect to B, and for ev ery subsequent side effect, it is not the case that B happens before it. The value of an atomic object M, as determined by evaluation B, shall be the value stored by some operation in the visible sequence of M with respect to B. Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and the value computed by A corresponds to the value stored by side effect X, then the value computed by B shall either equal the value computed by A, or be the value stored by side effect Y, where Y follows X in the modification order of M. 23 NOTE 10 This effectively disallows compiler reordering of atomic operations to a single object, even if both operations are ‘‘relaxed’’ loads. By doing so, we effectively make the ‘‘cache coherence’’ guarantee provided by most hardware available to C atomic operations. 24 NOTE 11 The visible sequence depends on the ‘‘happens before’’ relation, which in turn depends on the values observed by loads of atomics, which we are restricting here. The intended reading is that there must exist an association of atomic loads with modifications they observe that, together with suitably chosen modification orders and the ‘‘happens before’’ relation derived as described above, satisfy the resulting constraints as imposed here. 25 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. 26 NOTE 12 It can be shown that programs that correctly use simple mutexes and memory_order_seq_cst operations to prevent all data races, and use no other synchronization operations, behave as though the operations executed by their constituent threads were simply interleaved, with each value computation of an object being the last value stored in that interleaving. This is normally referred to as ‘‘sequential consistency’’. However, this applies only to data-race-free programs, and datarace-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. 20 Environment §5.1.2.4
CISO/IEC2011-AllrightsreservedISO/IEC9899:2011 (E)NOTE133Compilertransformations that introduce assignments to a potentially shared memory location27that would not bemodified bythe abstract machine aregenerally precluded by this standard, since such anassignment might overwrite anotherassignmentbya different thread in cases in which an abstract machineexecution would not have encountered a data race.This includes implementations of data memberassignmentthatoverwrite adjacentmembers in separatememorylocations.We also generallyprecludereordering of atomic loads in cases in which the atomics in question may alias,since this may violate the"visiblesequence"rulesNOTE14Transformations that introduce a speculative read ofa potentially sharedmemory location may28not preserve the semantics of the program as defined in this standard, since they potentially introduce a datarace.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 nottolerant of races orprovideshardwareracedetection21$5.1.2.4Environment
© ISO/IEC 2011 − All rights reserved ISO/IEC 9899:2011 (E) 27 NOTE 13 Compiler transformations that introduce assignments to a potentially shared memory location that would not be modified by the abstract machine are generally precluded by this standard, since such an assignment might overwrite another assignment by a different thread in cases in which an abstract machine execution would not have encountered a data race. This includes implementations of data member assignment that overwrite adjacent members in separate memory locations. We also generally preclude reordering of atomic loads in cases in which the atomics in question may alias, since this may violate the "visible sequence" rules. 28 NOTE 14 Transformations that introduce a speculative read of a potentially shared memory location may not preserve the semantics of the program as defined in this standard, since they potentially introduce a data race. However, they are typically valid in the context of an optimizing compiler that targets a specific machine with well-defined semantics for data races. They would be invalid for a hypothetical machine that is not tolerant of races or provides hardware race detection. §5.1.2.4 Environment 21
ISO/IEC9899:2011 (E)ISO/IEC2011-Allrightsreserved5.2Environmentalconsiderations5.2.1 Character setsTwo sets of characters and their associated collating sequences shall be defined: the set inEwhich sourcefiles are written(the source character set),and the set interpreted in theexecution environment(the executioncharacter set).Each set is further divided into abasic character set,whose contents are givenbythis subclause,and a set of zeroor morelocale-specific members (whichare not members of the basic character set)calledextended characters. The combined set is also called the extended character set. Thevalues of the members of the execution character set are implementation-defined.2Inacharacter constant or stringliteral,membersof theexecution characterset shall berepresented by corresponding members of the source character set or by escapesequences consisting of thebackslash\followed by one or more characters.Abyte withall bits set to O, called the null character, shall exist in the basic execution character set, itisusedtoterminateacharacterstring3Both the basic source and basic execution character sets shall have the followingmembers:the26uppercaselettersof theLatinalphabetEFGHKLMABCDIJTNoPRsUVWXYZQthe26lowercaselettersoftheLatinalphabetfhbdgijk1acemtrsuvwYn0zPqthe10decimal digitso234567891the following29graphic characters缘1%&(1?<the space character, and control characters representing horizontal tab, vertical tab, andform feed.The representation of each member of the source and execution basiccharacter sets shall fit in a byte. In both the source and execution basic character sets, thevalue of each character after o in the above list of decimal digits shall be one greater thanthe value of the previous. In source files, there shall be some way of indicating the end ofeach lineof text;this International Standard treats such an end-of-line indicator as if itwere a single new-line character. In the basic execution character set, there shall becontrol characters representing alert, backspace, carriage return, and new line.If anyother characters are encountered in a source file (except in an identifier, a characterconstant, a string literal,a header name,a comment, or a preprocessing token that is never22Environment$5.2.1
ISO/IEC 9899:2011 (E) © ISO/IEC 2011 − All rights reserved 5.2 Environmental considerations 5.2.1 Character sets 1 Tw o sets of characters and their associated collating sequences shall be defined: the set in which source files are written (the source character set), and the set interpreted in the execution environment (the execution character set). Each set is further divided into a basic character set, whose contents are given by this subclause, and a set of zero or more locale-specific members (which are not members of the basic character set) called extended characters. The combined set is also called the extended character set. The values of the members of the execution character set are implementation-defined. 2 In a character constant or string literal, members of the execution character set shall be represented by corresponding members of the source character set or by escape sequences consisting of the backslash \ followed by one or more characters. A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string. 3 Both the basic source and basic execution character sets shall have the following members: the 26 uppercase letters of the Latin alphabet ABCDEFGHIJKLM NOPQRSTUVWXYZ the 26 lowercase letters of the Latin alphabet abcdefghijklm nopqrstuvwxyz the 10 decimal digits 0123456789 the following 29 graphic characters !"#%&'()*+,-./: ;<=>?[\]^_{|}~ the space character, and control characters representing horizontal tab, vertical tab, and form feed. The representation of each member of the source and execution basic character sets shall fit in a byte. In both the source and execution basic character sets, the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous. In source files, there shall be some way of indicating the end of each line of text; this International Standard treats such an end-of-line indicator as if it were a single new-line character. In the basic execution character set, there shall be control characters representing alert, backspace, carriage return, and new line. If any other characters are encountered in a source file (except in an identifier, a character constant, a string literal, a header name, a comment, or a preprocessing token that is never 22 Environment §5.2.1