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.
For more options, visit https://groups.google.com/d/optout.
