Repository navigation
[intro.races] CWG 2297, LWG 2506: Unclear specification of atomic operations #1611
Description
Activity
I'm not seeing where we normatively say "new and delete are defined to be synchronization operations".
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].
- added a commit that references this issue
on Apr 12, 2017 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]?
@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.)
we don't say anything about visibility of unrelated memory updates
The "happens before" part almost does that (but for consume operations).
@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.
@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...
- added a commit that references this issue
on Jul 21, 2017 - added a commit that references this issue
on Jul 30, 2017 - added a commit that references this issue
on Oct 15, 2017 This is covered by LWG 2506.
- changed the title
[-][intro.races] CWG 2297: Unclear specification of atomic operations[/-][+][intro.races] CWG 2297, LWG 2506: Unclear specification of atomic operations[/+]on Apr 13, 2018 SG1 discussion on LWG 2506 asked for a paper to address "atomic object", "atomic operation", "synchronization operation" etc.
Reacted by A. Jiang
CWG telecon 2017-04-10 determined this issue was editorial.