Ø … 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.
