In the OP, I don't think `#1` must be visible to `#4` when `now1 < now2`.
As I said above, the visibility is guaranteed by the happens-before that
has a strict definition in the specification. To avoid over-focus on the
inter-thread happens-before, I think the original question can be
simplified as an example that only comprises a single thread.

````cpp

#include <atomic>
#include <chrono>

std::atomic<int> val = 0;int main(){
  val.store(1,std::memory_order::relaxed); // #1
  auto c1 = std::chrono::steady_clock::now(); // #2
}

````

The control flow first executes `#1`, then `#2`, while the control flow
executing `#2` samples a global time point. So, the question is: Is `#1`
executed by the control flow at a point in time that is no later than the
time point represented by `c1`? Note that we only talk about this question
in the abstract machine.

On Thu, Jun 11, 2026 at 3:22 PM Jennifier Burnett <jenni_at_[hidden]>
wrote:

> Happens-before is very relevant because the question is about visibility
> between threads. The sequencing of statements in c++ is defined by the
> sequenced-before relation, which is implicitly upgraded to a happens-before
> relationship. The OP is asking if a write on one thread must become visible
> to a read on another thread if the latter observes a later time point from
> a call that is sequenced-before the read than the prior does from a call
> that is sequenced-after the write. Without a happens-before relationship
> between the read and the write that simply isn't possible because of
> trivial hardware optimisations like store buffering. Just because an
> execution on one thread happens temporally after an execution on another
> thread does not necessarily mean that the later execution has the same view
> of memory that the earlier one does.
>
> My point is that unless you consider that observing a time point counts as
> a type of write there's no way of establishing the release part of the
> acquire-release relationship that's required for creating the
> happens-before.
>
>
> On 11 June 2026 06:51:46 BST, jim x <xmh970252187_at_[hidden]> wrote:
>
>>
>> What exactly would you be establishing a happens-before relationship with
>>> in the original example?
>>>
>>
>> This is the misunderstanding of the OP. The OP doesn't talk about the
>> happens-before relationship; instead, the intention can be simplified as
>> talking about whether the control flow executing a previous expression
>> occurs in no later time point than the time point it executes a later
>> expression.
>>
>> On Thu, Jun 11, 2026 at 1:37 PM Jennifier Burnett via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>>
>>> An acquire barrier is meaningless in this context. An acquire barrier
>>> needs either a release operation or atomic operation preceded by a release
>>> barrier to have any semantics beyond relaxed. What exactly would you be
>>> establishing a happens-before relationship with in the original example?
>>> Assuming the call to now() is an implicit acquire barrier changes nothing
>>> about the semantics because there's no corresponding release for it to
>>> establish a happens-before relationship with. The first thread doesn't even
>>> have any operations other than the call to now() that the acquire barrier
>>> would apply to
>>>
>>> On 11 June 2026 01:37:42 BST, Thiago Macieira via Std-Discussion <
>>> std-discussion_at_[hidden]> wrote:
>>> >On Wednesday, 10 June 2026 16:24:30 Pacific Daylight Time Simon Cooke
>>> wrote:
>>> >> If you don't want that, you need acquire semantics, which will
>>> prevent the
>>> >> write from down after the timestamp() call in #2
>>> >
>>> >This is the essence of the argument: reading from the monotonic clock
>>> should
>>> >be an acquire barrier. The Standard does not say it is, but I think it
>>> should.
>>> >
>>> --
>>> Std-Discussion mailing list
>>> Std-Discussion_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>
>>