Golang assignment safety with single reader and single writer

[w jp]

I'm not sure if this post fits here coz it's more about concurrency. I'm trying to reasoning if I could get by without atomic or other synchronization in this case.

So I have two go routines:

var sequence int64

// writer
for i := sequence; i < max; i++ {
  doSomethingWithSequence(i)
  sequence = i
}

// reader
for {
  doSomeOtherThingWithSequence(sequence)
}

And here're some potential risks I can think of:

1. reordering (for the writer, updating sequence happens before doSomething) could happen, but I can live with that.

2. sequence is not properly aligned in memory so the reader might observe a partially updated sequence. Running on (recent kernel) linux with x86_64, can we rule that out?

3. go compiler 'cleverly optimizes' the reader, so the access to i never goes to memory but 'stayed' in a register. Is that possible in go?

4. Anything else?

PS: I posted same thing on SO but people seem to be more focused on educating me about not going there, but that's really not my point. 

[Martin Thompson]

When programming with threads you have to respect the language memory model to have a chance of creating correct code. I don't get what point you are trying for here.

If your goal is to learn then maybe read up on memory models and compiler optimisations. The people on SO might have a point ;-)

[Michael Barker]

Hi

The Golang memory model is described here: https://golang.org/ref/mem. Note that it does not include any information about how atomics interact (still an open issue: https://github.com/golang/go/issues/5045). So with Golang you can't make any useful assumptions beyond what is described.  Behaviour may even test as correct and break as soon as you change CPU or compiler revision, or if you change your code and it decides to apply different optimisations.  If you are interested in concurrency at the levels you describe, you might want to look at a language with a more detailed memory model e.g. C++, Java.

Mike.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/31e1ab4e-8581-45e9-9419-6f7f80c41281%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[w jp]

Thx I've read that already. So can we conclude this is UNDEFINED?

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[w jp]

It's more like a thinking practice that occurred to me while working, so yeah that kind of education is not what I need on this one. :)