I'm having trouble finding definitive information about golang's preemption model when running with GOMAXPROCS>1 on a multi-core Intel with preemtive linux kernel.
As I understand it, in such a scenario, two goroutines may be scheduled by the go runtime onto two separate system threads on two separate CPUs. Isn't it true then, that irrespective of whether the two goroutines are scheduled onto separate CPUs, the OS may preemptively interrupt either of those goroutines to let the other run? Also, that if they are indeed scheduled onto separate CPUs, that the memory accesses made by those goroutines are interleaved even if no individual goroutine is "preempted"? I'm asking because in reviewing the code of some "lock free" concurrent data structures written in go, it appears the authors have made certain assumptions about race conditions (e.g., the code of on goroutine assumes that another goroutine won't perform a load/store between two function calls the first goroutine makes to check a boolean and store a value). Given that goroutines are mappes onto system threads, and that in a preemptive kernel those threads may be preempted and/or irrespective of the preemptive kernel issue may run on separate cores, no assumptions should be made about the "atomicity" of multiple statements in a goroutine relative to other goroutines. Right? Where can I get the most current and accurate information about this topic? A. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0912663b-d4cb-41ee-a335-466c74b00d8cn%40googlegroups.com.
