>
> 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?


A conforming implementation can do that; however, the standard doesn't
specify that this is implementation-defined, i.e., this part is not
parameterized from the perspective of the C++ standard; therefore, the
semantics of the operations are always determined in the abstract machine,
and such operations are non-atomic. Unlike the semantics of access through
the volatile glvalue, which are implementation-defined, this is
a nondetermined parameter to the abstract machine, so the implementation
can specify the parameter for the abstract machine such that the semantics
are specified as being equivalent to `std::atomic_ref::load()/store()`, my
concern is about whether such specified semantics can be viewed as atomic
under [intro.race] p17.

On Wed, Oct 14, 2026 at 12:38 PM Tom Honermann <tom_at_[hidden]> wrote:

> 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
>
>