Thanks for clarifying that Ian!

On Wed, Oct 12, 2016, 19:21 Ian Lance Taylor <i...@golang.org> wrote:

> On Wed, Oct 12, 2016 at 9:39 AM, Konstantin Khomoutov
> <flatw...@users.sourceforge.net> wrote:
> > On Wed, 12 Oct 2016 07:36:15 -0500
> > John Souvestre <j...@souvestre.com> wrote:
> >
> >> Interesting.  I didn’t realize that thread was live again.  I thought
> >> that this one put it to rest.
> >>
> https://groups.google.com/forum/#!msg/golang-nuts/7EnEhM3U7B8/nKCZ17yAtZwJ
> >>
> >> I don’t know for sure, but I imagine that Russ’ statement about
> >> atomics was mainly concerning synchronization – which Go’s
> >> sync/atomic operations provide.  And I would certainly agree.
> >
> > I surely maybe completely wrong in interpreting what Henrik Johansson
> > tries to express but I think I share confusion with him on this point so
> > let me try to express it in different words.
> >
> > I assume you're correct that on today's popular H/W architectures
> > functions of the sync/atomic package emit a memory barrier and hence
> > stuff like
> >
> >   // goroutine 1
> >   data = 42
> >   atomic.StoreInt32(&ready, 1)
> >
> >   // goroutine 2
> >   for {
> >     if atomic.CompareAndSwapInt32(&ready, 1, 0) {
> >       break
> >     }
> >     runtime.Gosched()
> >   }
> >   if data != 42 {
> >     panic("broken")
> >   }
> >
> > works because those memory barriers are full—and hence "global".
> >
> > But the crucial point is that this is an implicit and unspecified
> > (as in "not in the spec") property of those operations.
> >
> > I, for one, can't see why atomic.Store() has to issue a full memory
> > barrier at all: as I understand the sole guarantee of its "atomicity"
> > property is that no reader of the affected memory region will observe a
> > so-called "partial update" when atomic.Store() performs that update.
> > Now suppose some (future or existing) H/W arch would allow maintaining
> > this "readers see no partial update" invariant while not issuing a
> > memory fence.  In this case the value read from the "data" variable in
> > the second goroutine in the example above may legitimately be != 42.
> > To rephrase, I fail to see how a pair of store/CAS functions from
> > sync/atomic enforce the "happens before" relationship on anything
> > except the precise memory region under a variable they operate on.
> >
> > To quote the Wikipedia article on memory barriers [1]:
> >
> > | Some architectures, including the ubiquitous x86/x64, provide several
> > | memory barrier instructions including an instruction sometimes called
> > | "full fence". A full fence ensures that all load and store operations
> > | prior to the fence will have been committed prior to any loads and
> > | stores issued following the fence. Other architectures, such as the
> > | Itanium, provide separate "acquire" and "release" memory barriers
> > | which address the visibility of read-after-write operations from the
> > | point of view of a reader (sink) or writer (source) respectively.
> > | Some architectures provide separate memory barriers to control
> > | ordering between different combinations of system memory and I/O
> > | memory. When more than one memory barrier instruction is available it
> > | is important to consider that the cost of different instructions may
> > | vary considerably.
> >
> > So, above I was actually referring to those «separate "acquire" and
> > "release" memory barriers».
> >
> > Could you please clear this confusion up for me?
>
>
> I think I've lost the context here, but: 1) I agree that sync/atomic
> should ideally have more details in the memory model
> (https://golang.org/issue/5045); 2) atomic.LoadXX is either a full
> barrier or a load-acquire, and atomic.StoreXX is either a full barrier
> or a store-release.  EIther way, goroutine 2 will see the value
> assigned to data in goroutine 1.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to