[intro.execution] p8 "evaluated strictly according to the rules of the abstract machine" is unclear

[xmh0511]

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

[intro.execution] p8 says:

The following specify the observable behavior of the program:

• Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.
• Data is delivered to the host environment to be written into files (See also: ISO/IEC 9899:2024, 7.23.3).
• The input and output dynamics of interactive devices shall take place in such a fashion that prompting output is actually delivered before a program waits for input. What constitutes an interactive device is implementation-defined.

Consider this example:

#include <chrono>

int main(){
   volatile int v = 0;
   v = 1; // #0
   std::this_thread::sleep_for(std::chrono::milliseconds(50000));  // #1
   v = 2; // #2
}

The effect of #1 is

Blocks the calling thread for the relative timeout ([thread.req.timing]) specified by rel_time.

sleep_for, according to its specification, is not an observable behavior itself according to the definition of observable behavior. However, the access to the volatile glvalue is an observable behavior. The current wording only requires a conforming implementation to evaluate them strictly according to the abstract machine's rules. Does this rule only involve visibility, and must every evaluation be preserved?

In other words, can a conforming implementation eliminate the call to sleep_for according to the "as-if" rule? The current wording, "are evaluated strictly according to the rules of the abstract machine", is not very clear about this point.

[safocl]

std::this_thread::sleep_for(std::chrono::milliseconds(50000));  // #1

What observable program behavior do you expect to see from this?

[safocl]

sleep_for, according to its specification, is not an observable behavior itself according to the definition of observable behavior.

The current wording, "are evaluated strictly according to the rules of the abstract machine", is not very clear about this point.

Perhaps it should not in any way affect the aspect you have indicated, following your own reasoning above?

In other words, how can a rule be unclear about what the rule does not describe (what it does not apply to)?

[xmh0511]

sleep_for, according to its specification, is not an observable behavior itself according to the definition of observable behavior.

The current wording, "are evaluated strictly according to the rules of the abstract machine", is not very clear about this point.

Perhaps it should not in any way affect the aspect you have indicated, following your own reasoning above?

In other words, how can a rule be unclear about what the rule does not describe (what it does not apply to)?

You seem not to understand the issue yet.

[safocl]

You seem not to understand the issue yet.

In my opinion, there's no problem here; everything is clearly stated in the standard, even down to the wording. For me personally, it's completely clear.

[xmh0511]

You seem not to understand the issue yet.

In my opinion, there's no problem here; everything is clearly stated in the standard, even down to the wording. For me personally, it's completely clear.

You didn't express your opinion at all. Do you mean #1 can be eliminated in a conforming implementation?

[xmh0511]

std::this_thread::sleep_for(std::chrono::milliseconds(50000)); // #1

What observable program behavior do you expect to see from this?

The issue is whether we must observe v==2 at least 50,000 milliseconds after observing v==1.

[safocl]

Do you mean #1 can be eliminated in a conforming implementation?

No, but where does it say it can be eliminated if it's not observable behavior?

[safocl]

The issue is whether we must observe v==2 at least 50,000 milliseconds after observing v==1.

No, if you read carefully, it's talking exclusively about access through volatile glvalue.

[safocl]

I think everything here is logical, since observable behavior refers to behavior that changes the state of some external entities in the system. They are specifically "visible from the system."

[safocl]

In my opinion, the true reasoning in this topic evaluates the provisions of [intro.multithread.general] and [thread.threads#general-1], and others, related specifically to program execution, and is not related to the abstract machine itself in the context specified in [intro.abstract].

[xmh0511]

Do you mean #1 can be eliminated in a conforming implementation?

No, but where does it say it can be eliminated if it's not observable behavior?

Isn't it said by as-if rule?

[safocl]

Isn't it said by as-if rule?

The semantic descriptions in this document define a parameterized nondeterministic abstract machine. This document places no requirement on the structure of conforming implementations. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.

but in that case you should create a discussion about the contradiction of this rule and, let's say, for example, [basic.exec]

[leni536]

sleep_for, according to its specification, is not an observable behavior itself according to the definition of observable behavior. However, the access to the volatile glvalue is an observable behavior. The current wording only requires a conforming implementation to evaluate them strictly according to the abstract machine's rules. Does this rule only involve visibility, and must every evaluation be preserved?

In other words, can a conforming implementation eliminate the call to sleep_for according to the "as-if" rule? The current wording, "are evaluated strictly according to the rules of the abstract machine", is not very clear about this point.

I think you are right, and a call to sleep_for has no observable normative effect, and a conforming implementation might have those accesses to v less then 50 seconds apart.

For example a conforming implementation might have a deliberately sped up clock, maybe to exercise timeouts in functional tests without actually spending the wall clock time in CI.

[safocl]

For example a conforming implementation might have a deliberately sped up clock, maybe to exercise timeouts in functional tests without actually spending the wall clock time in CI.

but this is more related to the implementation of the clock itself in the system, and not to the fact that the "sleep" call itself can be ignored by the implementation.

[xmh0511]

For example a conforming implementation might have a deliberately sped up clock, maybe to exercise timeouts in functional tests without actually spending the wall clock time in CI.

but this is more related to the implementation of the clock itself in the system, and not to the fact that the "sleep" call itself can be ignored by the implementation.

See

The semantic descriptions in this document define a parameterized nondeterministic abstract machine. This document places no requirement on the structure of conforming implementations. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.