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.
