Date: Thu, 11 Jun 2026 14:08:46 -0700
On Thursday, 11 June 2026 14:03:20 Pacific Daylight Time Jennifier Burnett
wrote:
> > I meant that if you can tell that x was stored to, then it must have been
> > stored a value lesser than or equal to TIME().
>
> I think it's maybe just poorly formulated then - you need to both detect the
> value written flag and then ensure that if the flag is set you read the
> correct value from the dependent field, which you need to use
> acquire-release for.
Agreed it's poorly-formulated, but that's an effect of the OP's proposal being
such poorly-formulated. In my exercise, we detect that it's been written by
checking the value read against a sentinel.
> Since this is a thought experiment you can just
> declare that certain reads observe a particular value, so
>
> ```
> T1:
> x = TIME()
> y.store(x,relaxed)
> T2:
> z = y.load(relaxed) //reads x
> assert(z <= TIME())
> ```
>
> should work fine at demonstrating the problem. The issue is that you need to
> formulate a way of letting TIME establish a happens-before relationship
> with the other call through the two relaxed operations, which are only
> related by the coherence-ordered-before relation. Having an acquire barrier
> before reading the time point and a release barrier after would do the
> trick, and declaring that TIME acts as an acq_rel fence would also work as
> a shortcut. Both of those work by upgrading the surrounding relaxed
> operations to be tantamount to acq_rel, though, which you may or may not
> think is a reasonable cost.
I'm not convinced we need an acq_rel barrier. It may be that we do and the
Standard should call out that now() calls should effectively have such a
barrier, if not literally have one such. But I think we only need an acquire
barrier, if we assume the clock ticking is a release barrier.
wrote:
> > I meant that if you can tell that x was stored to, then it must have been
> > stored a value lesser than or equal to TIME().
>
> I think it's maybe just poorly formulated then - you need to both detect the
> value written flag and then ensure that if the flag is set you read the
> correct value from the dependent field, which you need to use
> acquire-release for.
Agreed it's poorly-formulated, but that's an effect of the OP's proposal being
such poorly-formulated. In my exercise, we detect that it's been written by
checking the value read against a sentinel.
> Since this is a thought experiment you can just
> declare that certain reads observe a particular value, so
>
> ```
> T1:
> x = TIME()
> y.store(x,relaxed)
> T2:
> z = y.load(relaxed) //reads x
> assert(z <= TIME())
> ```
>
> should work fine at demonstrating the problem. The issue is that you need to
> formulate a way of letting TIME establish a happens-before relationship
> with the other call through the two relaxed operations, which are only
> related by the coherence-ordered-before relation. Having an acquire barrier
> before reading the time point and a release barrier after would do the
> trick, and declaring that TIME acts as an acq_rel fence would also work as
> a shortcut. Both of those work by upgrading the surrounding relaxed
> operations to be tantamount to acq_rel, though, which you may or may not
> think is a reasonable cost.
I'm not convinced we need an acq_rel barrier. It may be that we do and the
Standard should call out that now() calls should effectively have such a
barrier, if not literally have one such. But I think we only need an acquire
barrier, if we assume the clock ticking is a release barrier.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-06-11 21:08:55
