[intro.races] p17 Define the meaing of the "atomic"

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

[intro.races] p17 states

Two actions are potentially concurrent if

• [...]

The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below.

What do the atomic actions intend to mean here? Does it only refer to these operations defined for atomic<T>? Or does it refer to these operations that are semantically specified as atomic operations? For example, [thread.mutex.requirements.mutex.general] p4 states:

The implementation provides lock and unlock operations, as described below. For purposes of determining the existence of a data race, these behave as atomic operations ([intro.multithread]).

"behave as atomic operations" sounds like these operations are semantically specified as atomic operations. Furthermore, are the atomic operations referred to in [intro.races] p17 admit these operations, where the implementation defines them as atomic operations since their semantics are implementation-defined?

Suggested Resolution:

[safocl]

"operations" are tied to "atomic objects" in the context of [intro.races].

[frederick-vs-ja]

This is already touched in LWG2506.

[xmh0511]

@frederick-vs-ja To follow up on #1008 (comment)

I think the clarification of what constitutes an "atomic operation" under [intro.race] needs to explicitly account for whether this set is strictly closed, and clarify how implementation-defined semantics interact with it.

Consider the following example:

#include <thread>
#include <atomic>

int main(){
  volatile int value = 0;
  std::jthread t1([&](){
    auto i = value; // #1
  });
  std::jthread t2([&](){
     value = 1; // #2
  });
}

The access semantics of a volatile glvalue are implementation-defined ([intro.execution]). Suppose an implementation documents that the read at #1 is equivalent to std::atomic_ref(value).load() and the write at #2 is equivalent to std::atomic_ref(value).store(1). Both of these underlying operations are standard atomic operations specified in Clause 31.

The crucial question is: Do #1 and #2 qualify as "atomic operations" under [intro.race] p17, thereby preventing a data race?

1. Interpretation A (Closed/Exhaustive set): The set of atomic operations recognized by [intro.race] is strictly bounded by the standard. An implementation cannot synthesize new atomic operations out of arbitrary expressions—even if it defines their semantics in terms of standard atomic primitives. Under this view, #1 and #2 remain non-atomic at the abstract machine level, meaning this program still formally contains a data race.
2. Interpretation B (Extensible via implementation-defined semantics): An implementation is permitted to confer atomic status upon implementation-defined operations by mapping them to standard atomic operations.

I hope the clarification of "atomic" referred to in [intro.race] p17 will unambiguously mean the first one.

[frederick-vs-ja]

From discussions in LWG2506:

SG1 consensus is that operations outside clause 32 are not "atomic operations", and objects of types defined outside clause 32 are not "atomic objects". "Synchronization operations" are operations which act as endpoints of primitive edges of partial orders other than sequenced-before, but it may make more sense to just drop that term and inline the definition, so to speak.

IIUC, SG1 agreed on that the standard meaning of "atomic operations" is not customizable. Although there's not yet such a paper for the consensus after 8.5 years.

In any case this can be considered as duplicate of an existing issue.

[xmh0511]

IIUC, SG1 agreed on that the standard meaning of "atomic operations" is not customizable.

The point is that the specified semantics don't create new "atomic operations"; the semantics use std::atomic_ref(value).load()/store(), which are the atomic operations in clause 32.

[xmh0511]

@frederick-vs-ja In other words, if an implementation defines the semantics of an access in terms of std::atomic_ref(value).load()/store() (i.e., operations designated as atomic in Clause 32), does this access qualify as an atomic operation under [intro.race] p17? If not, why would an access with such semantics fail to be considered an atomic operation in that context, given that the corresponding std::atomic_ref(value).load()/store() itself qualifies?

I think this is the reason why we need to clarify the intent of the "atomic" referred to in [intro.race] p17.

[frederick-vs-ja]

Now it seems to me that this issue is asking for something other than clarifying the meaning of atomic operations. Maybe the title should be reworded.

I guess we should clarify the bound of implementation-defined choices for [dcl.type.cv] p5 instead if a new issue is wanted.

[xmh0511]

Now it seems to me that this issue is asking for something other than clarifying the meaning of atomic operations. Maybe the title should be reworded.

I guess we should clarify the bound of implementation-defined choices for [dcl.type.cv] p5 instead if a new issue is wanted.

Check this new issue #1013