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.
