On Thu, Jul 18, 2019 at 8:35 AM T L <tapir....@gmail.com> wrote:
>
> For example:
>
> type Page struct {
> views uint32
> }
>
> func (page *Page) SetViews(n uint32) {
> atomic.StoreUint32(&page.views, n)
> }
>
> func (page *Page) Views() uint32 {
> return atomic.LoadUint32(&page.views)
> }
>
> Keith Randall and Ian Lance Taylor said that atomic.Load is a
> memory_order_acquire
> and atomic.Store is memory_order_release, so there is no memory order
> guarantees
> between the following two calls, I think:
>
> atomic.StoreUint32(&page.views, n)
> atomic.LoadUint32(&page.views)
>
> In other words, the load result might not reflect the latest value of
> page.views.
In these kinds of discussions it's hard to know what "latest value"
means. But in general an atomic load will see any atomic store that
preceded it in absolute time. The difference between load-acquire and
sequentially-consistent-load is not with the atomic value itself; it's
with all other memory accesses. The LoadUint32 will see the
StoreUint32, but it may not see any other non-atomic memory stores
done before the StoreUint32.
> On the contrary, the memory order between the following two calls
> is guaranteed to be as their order shown in code.
>
> atomic.LoadUint32(&page.views)
> atomic.StoreUint32(&page.views, n)
>
> Is my understanding right?
So, per above, not quite.
And that said, see the more recent discussion on
https://golang.org/issue/5045, in which Russ argues that we should use
sequential consistency anyhow.
Ian
--
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/CAOyqgcUz5vZeJj9jDk3YgU3kP0GmvY7nKkYqib4E-gcXGM1yjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
