2506. Underspecification of atomics

Section: 6.8.2 [intro.multithread], 32.6 [atomics.types.generic], 21.11 [support.runtime] Status: New Submitter: Geoffrey Romer Opened: 2015-05-29 Last modified: 2015-09-23

Priority: 3

View all other issues in [intro.multithread].

View all issues with New status.

Discussion:

The concurrency libraries specified in clauses 29 and 30 do not adequately specify how they relate to the concurrency model specified in 6.8.2 [intro.multithread]. In particular:

6.8.2 [intro.multithread] specifies "atomic objects" as having certain properties. I can only assume that instances of the classes defined in Clause 29 are intended to be "atomic objects" in this sense, but I can't find any wording to specify that, and it's genuinely unclear whether Clause 30 objects are atomic objects. In fact, on a literal reading the C++ Standard doesn't appear to provide any portable way to create an atomic object, or even determine whether an object is an atomic object.

(It's not clear if the term "atomic object" is actually needed, given that atomic objects can have non-atomic operations, and non-atomic objects can have atomic operations. But even if the term itself goes away, there still needs to be some indication that Clause 29 objects have the properties currently attributed to atomic objects).

Similarly, 6.8.2 [intro.multithread] uses "atomic operation" as a term of art, but the standard never unambiguously identifies any operation as an "atomic operation" (although in one case it unambiguously identifies an operation that is not atomic). It does come close in a few cases, but not close enough:

Proposed resolution: