Ø . The only reason I hesitate to go further is because that isn't formalized as part of the spec I don't believe, hence the issue.
I believe it is. From the Go Memory Model: “To serialize access, protect the data with channel operations or other synchronization primitives such as those in the <https://golang.org/pkg/sync/> sync and <https://golang.org/pkg/sync/atomic/> sync/atomic packages.” John John Souvestre - New Orleans LA From: hiatt.dus...@gmail.com [mailto:hiatt.dus...@gmail.com] Sent: 2016 October 12, Wed 09:05 To: golang-nuts Cc: j...@souvestre.com Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() I think what Russ is saying there is don't do // routine 1 x = 5 // routine 2 atomic.LoadInt32(&x) That's mixing atomic operations on the same word. In the case of a spin lock to coordinate threads, Dmitriy's comment 15 is illustrative: 1. // goroutine 1 data = 42 atomic.Store(&ready, 1) // goroutine 2 if atomic.Load(&ready) { if data != 42 { panic("broken") } } I'm pretty sure the above case works in go without panicking and there is causal ordering here. The only reason I hesitate to go further is because that isn't formalized as part of the spec I don't believe, hence the issue. On Wednesday, October 12, 2016 at 6:16:00 AM UTC-5, Henrik Johansson wrote: I am sorry if I am dense but what Russ said in that thread "and that you shouldn't mix atomic and non-atomic accesses for a given memory word" seems to indicate otherwise. I am not going to use spin locks left and right but just understand the workings and adjust my expectations accordingly. ons 12 okt. 2016 kl 10:16 skrev John Souvestre <jo...@souvestre.com <javascript:> >: I looked at pi/goal. It uses a sync/atomic CAS. Thus, yes, it provides a memory barrier. As someone else already recommended, the call to Gosched() for each loop will probably tie up the runtime quite a bit. It would probably be better to drop it entirely (if the spin isn’t going to last long, worst case) or only do it every so often (perhaps 1,000 or more loops). Depending on the amount of congestion and what your latency goal is, you might find that a regular sync/Mutex does as well or better. The fast path (when there’s little congestion) isn’t much more than a CAS. John John Souvestre - New Orleans LA From: Henrik Johansson [mailto:dahan...@gmail.com <javascript:> ] Sent: 2016 October 12, Wed 03:02 To: John Souvestre; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() Sure that's my question. Does a SpinLock as given in several examples above provide the same semantics as a proper mutex? On Wed, Oct 12, 2016, 09:50 John Souvestre <jo...@souvestre.com <javascript:> > wrote: Ø … state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? I believe that any of the atomic operations in sync/atomic is a memory barrier, just as a mutex is, and this is for all platforms. Ø Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? Not if everyone accessing them is using a mutex to synchronize the access. John John Souvestre - New Orleans LA From: golan...@googlegroups.com <javascript:> [mailto:golan...@googlegroups.com <javascript:> ] On Behalf Of Henrik Johansson Sent: 2016 October 12, Wed 00:02 To: hiatt....@gmail.com <javascript:> ; golang-nuts Subject: Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock() Yes I get that but it seems as there other constraints at play here wrt the memory model. In essence the spin locks (unless described outside their code somewhere) state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? My point is that the protected section isn't guaranteed the same memory rules as when protected by a standard lock. -- 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...@googlegroups.com <javascript:> . 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...@googlegroups.com <javascript:> . 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.
