Thx I've read that already. So can we conclude this is UNDEFINED? On Tuesday, July 2, 2019 at 3:32:48 AM UTC+8, mikeb01 wrote: > > 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] <javascript:>> > 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] <javascript:>. >> 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/3eba145e-686c-4b77-9a45-8eb305ff6511%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
