So mixing atomic read/write of one variable makes non-atomic read/writes of
another variable safe as well? As far as the memory model goes? Caveat
being that it's not formalized.
I am sure great care is needed when attempting such code regardless...
On Wed, Oct 12, 2016, 16:04 <hiatt.dus...@gmail.com> wrote:
> 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>:
>
> 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]
>
> *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> 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 [mailto:golan...@googlegroups.com] *On
> Behalf Of *Henrik Johansson
>
>
> *Sent:* 2016 October 12, Wed 00:02
>
> *To:* hiatt....@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...@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...@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.
