On Fri, Sep 16, 2022 at 01:26:05PM -0700, 'Keith Randall' via golang-nuts wrote:
> Atomic operations can establish happens-before relationships.
>
> initially, y==0.
>
> goroutine 1:
> x = 99
> atomic.Store(&y, 1)
>
> goroutine 2:
> if atomic.Load(&y) == 1 {
> println(x)
> }
>
> This program, if it prints anything, must print 99.
> "x=99" and "atomic.Store(&y,1)" are ordered by the sequenced-before
> relationship.
> "atomic.Load(&y)" and "println(x)" are likewise.
> "atomic.Store(&y,1)" and "atomic.Load(&y)" are ordered by the
> synchronized-before relationship (if the latter in fact reads the value
> written by the former).
> So according to the memory model, the x=99 statement happens-before the
> println(x) statement.
>
> We use this pattern all the time in the runtime.
But the subtle connection between the x and y in the goroutine 1 is not in any
way explicit, and as I understand, to provide the guarantees you've presented,
the compiler must consider any atomic write-like operation in the code of a
function to be a point at which all earlier stores must have their effects be
observable at any point in a running program which performs an atomic
read-like operation from the same memory location, right?
But I doubt there is any way for such fine-grained approach so basically any
atomic store must work like a full memory fence then.
Another question: if your code were read
| initially, y==0.
|
| goroutine 1:
| x = 42
| x = 99
| atomic.Store(&y, 1)
| x = 100
|
| goroutine 2:
| if atomic.Load(&y) == 1 {
| println(x)
| }
then would println have been guaranteed to still print 99 and not 100?
In other words, do I understand correctly that an atomic write-like operation
guarantees that all stores made by a goroutine before that operation must be
visible, but stores made afterwards may be visible or not visible?
Or, to put it differently, if the read from y in goroutine 2 sees a 1,
there's no way println(x) prints 42, but it may print 99 or 100.
..and also if x is not naturally aligned (I think it's impossible in Go) or
not "hardware atomic" - like a 64-bit integer on a 32-bit platform, -
println(x) could produce some weird value as a result of the torn write/torn
read which may happen when one core updates the x while another one reads it,
right?
[...]
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20221030171554.gr5u2vjt3mydm5f6%40carbon.
