Ø 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:[email protected]]
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 <[email protected]>:
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:[email protected]]
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 <[email protected]> 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: [email protected] [mailto:[email protected]] On
Behalf Of Henrik Johansson
Sent: 2016 October 12, Wed 00:02
To: [email protected]; 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 [email protected].
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 [email protected].
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
