I mean https://github.com/golang/go/issues/5045
ons 12 okt. 2016 kl 13:50 skrev John Souvestre <j...@souvestre.com>: > Ø 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’m not sure what thread you are referring to. In general it is best to > avoid the sync/atomic stuff unless you * really * need it for performance > and you take the time to understand it well. A mutex lock would not > prevent another goroutine from doing an atomic operation, for example. So > mixing the two could be disastrous. But there are some cases where it can > be done. > > > > John > > John Souvestre - New Orleans LA > > > > *From:* Henrik Johansson [mailto:dahankz...@gmail.com] > *Sent:* 2016 October 12, Wed 06:12 > > > *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() > > > > 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 <j...@souvestre.com>: > > 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:dahankz...@gmail.com] > *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 <j...@souvestre.com> 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:* golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] > *On Behalf Of *Henrik Johansson > *Sent:* 2016 October 12, Wed 00:02 > *To:* hiatt.dus...@gmail.com; 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+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. > > -- > 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.
