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. On Tue, 2 Jul 2019, 05:31 Martin Thompson, <[email protected]> wrote: > 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 ;-) > > On Monday, 1 July 2019 17:05:47 UTC+1, w jp wrote: >> >> 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. >> > -- > 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 [email protected]. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/31e1ab4e-8581-45e9-9419-6f7f80c41281%40googlegroups.com > <https://groups.google.com/d/msgid/mechanical-sympathy/31e1ab4e-8581-45e9-9419-6f7f80c41281%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CALwNKeQrs53QV%3DRGELLJEpLyb3U5hxh%3DTUh0u-T7_SLf6COnHA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
