Date: Thu, 11 Jun 2026 08:44:31 +0100
Okay so thinking about it a bit I think you're drifting to a slightly different problem than that showcased in the original question. I'll propose a new example:
```
T1:
x = TIME()
y.store(x, relaxed)
T2:
z = y.load(relaxed)
w = TIME()
```
To my understanding the question as you understand it is whether when z == x, w must >= x, correct?
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
>>
```
T1:
x = TIME()
y.store(x, relaxed)
T2:
z = y.load(relaxed)
w = TIME()
```
To my understanding the question as you understand it is whether when z == x, w must >= x, correct?
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
>>
Received on 2026-06-11 07:44:42
