This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
Section: 31.8.2 [atomics.types.operations] Status: C++11 Submitter: INCITS Opened: 2010-08-25 Last modified: 2017-06-16
Priority: Not Prioritized
View other active issues in [atomics.types.operations].
View all other issues in [atomics.types.operations].
View all issues with C++11 status.
Duplicate of: 1470, 1475, 1476, 1477
Addresses US-175, US-165, CH-23, GB-135
99 [atomics.types.operations.req] p. 25: The first sentence is grammatically incorrect.
[ 2010-10-28 Daniel adds: ]
Duplicate issue 1475 also has a proposed resolution, but both issues are resolved with below proposed resolution.
[ 2011-02-15 Howard fixes numbering, Hans improves the wording ]
[2011-02-24 Reflector discussion]
Moved to Tentatively Ready after 6 votes.
Change 99 [atomics.types.operations.req] p. 23 as indicated:
The effect of the compare-and-exchange operationsisif (memcmp(object, expected, sizeof(*object)) == 0) memcpy(object, &desired, sizeof(*object)); else memcpy(expected, object, sizeof(*object));
— end note ] [..]
Change 99 [atomics.types.operations.req] p. 25 as indicated:
25 Remark:When a compare-and-exchange is in a loop, the weak version will yield better performance on some platforms. When a weak compare-and-exchange would require a loop and a strong one would not, the strong one is preferable. — end note ]
The weak compare-and-exchange operations may fail spuriously, that is, return false while leaving the contents of memory pointed to by expected before the operation is the same that same as that of the object and the same as that of expected after the operation. [ Note: This spurious failure enables implementation of compare-and-exchange on a broader class of machines, e.g., loadlocked store-conditional machines. A consequence of spurious failure is that nearly all uses of weak compare-and-exchange will be in a loop.