Date: Wed, 14 Oct 2026 00:38:13 -0400
Set aside the implementation-defined behavior of volatile accesses for a moment and consider an implementation that guarantees that all accesses of objects of enumeration type are performed as atomic operations. Is an implementation permitted to do that? Sure. Should that guarantee offered by the implementation affect whether a program has a data race? Should the answer be any different for volatile qualified types vs any other type an implementation provides such a guarantee for?
I think what you are asking for is for the standard to specify that the semantics of atomic operations apply to an implementation-defined set of types. I think that would be an ok change to make, but what would be the practical effect? I don’t think there is one; the behavior of any particular program would still rest on implementation provided guarantees; it doesn’t matter if those guarantees fall within behavior that is formally implementation-defined.
Is this just an academic concern for you? Or are you asking the question because you think it will materially affect whether one or more specific implementations conform to the standard? Are you asking because you have code that depends on volatile accesses being treated as atomic? Or because you want to write such code?
Tom.
On Oct 13, 2026, at 10:46 PM, jim x via Std-Discussion <std-discussion_at_[hidden]> wrote:
I'm trying to express the ambiguity I think about the wording.It doesn't say that accesses to volatiles *are* atomic.Yes. However, the standard simultaneously permits the implementation to define the semantics, which leaves a slot for implementations to define the parameterized part of the abstract machine. This leaves room for us to think about whether the operations associated with volatile glvalue are atomic or non-atomic because they are parameterized by the implementations. This is my confusion about the wording.--On Tue, Oct 13, 2026 at 10:52 PM Thiago Macieira <thiago_at_[hidden]> wrote:On Tuesday, 13 October 2026 01:43:01 Pacific Daylight Time jim x wrote:
> One of the grounds for your claim that the program exhibits undefined
> behavior is that you determined it contains a data race based on
> [intro.race] p17. But the very issue is: where does the standard state that
> an access to a volatile glvalue is non-atomic? The standard does not even
> define the semantics of such accesses and leaves them
> implementation-defined, making it even less possible to assert that
> accesses to a volatile glvalue are non-atomic. How, then, can you conclude
> based on [intro.race] that this program contains a data race?
It doesn't say that accesses to volatiles *are* atomic. Therefore, they aren't
required to be and thus your example is a data race.
jim, you've argued this over and over again. Everyone has the same
interpretation of the Standard except you and you keep arguing the same thing
over and over again. What do you want to happen? Do you want a Standard text
change to clarify things one way or another? If so, please propose it. Are you
trying to argue with a vendor about their functionality?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
Received on 2026-10-14 04:38:28