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.
