[intro.races] CWG 2297, LWG 2506: Unclear specification of atomic operations

[jensmaurer]

It is not sufficiently clear that the only atomic operations are the ones defined in clause 32 [atomics] by the library. The intent is that no accesses are atomic unless the Standard describes them as such.

An additional problem is that, e.g., new and delete are defined to be synchronization operations, but they are not defined in Clauses 32 [atomics] and 33 [thread].

CWG telecon 2017-04-10 determined this issue was editorial.

[jensmaurer]

I'm not seeing where we normatively say "new and delete are defined to be synchronization operations".

[jensmaurer]

It is not sufficiently clear that the only atomic operations are the ones defined in clause 32 [atomics] by the library. The intent is that no accesses are atomic unless the Standard describes them as such.

This is slightly confused. Since the standard does not define operations other than those in [atomics] to be "atomic operations", and furthermore we usually use "operation on atomic object M" when talking about ordering in [intro.races], there seems to be no leeway for a hostile interpretation.

The intent is that no accesses are atomic unless the Standard describes them as such.

A conforming implementation could make all accesses atomic, but a portable user program may only rely on atomic operations specified as such in the standard.

If there is any doubt what "atomic operations on atomic objects" are, it seems [intro.races] is not the place to fix it, but instead this should be addressed in [atomics].

[timsong-cpp]

I'm not seeing where we normatively say "new and delete are defined to be synchronization operations".

Maybe it's referring to the last sentence of [new.delete.dataraces]?

[jensmaurer]

@timsong-cpp: That still doesn't say that new/delete are synchronization operations; those make unrelated memory updates visible to other threads. In contrast, for new/delete we just specify that they are serializable as individual function calls, but we don't say anything about visibility of unrelated memory updates. (I'm not positive [new.delete.dataraces] actually says what it should say; we certainly want to allow thread-optimized allocators that respond to some allocations entirely locally without coordinating with other threads. See LWG 2508 for the opposite viewpoint; to be discussed.)

[timsong-cpp]

we don't say anything about visibility of unrelated memory updates

The "happens before" part almost does that (but for consume operations).

[jensmaurer]

@timsong-cpp: Fine, but I think that direction is misguided to start with. See http://lists.isocpp.org/parallel/2017/04/0856.php for discussion.

[timsong-cpp]

@jensmaurer I can't see what I can't access :) Was just trying to point out what IMO that portion of the comment probably meant, but I think this is getting a bit off-topic...

[jensmaurer]

This is covered by LWG 2506.