I recently heard someone say that Data Races in Go are Undefined Behavior. Is that true? I was unable to find a definite answer in the Go docs, but this talk says
Races on interface, string, slice, map entries can still do arbitrarily bad things
That is really surprising because Go is also widely considered a "safe" language! Java at least gives defined semantics to its data races to earn the "safe" label.
And then I checked Swift and the situation superficially seems similar? Does anyone know more?
I find it rather amusing (or concerning) that the Go memory model literally says nothing about data races...
"The Swift language guarantees memory safety in single threaded environments. However, conflicting accesses in multithreaded code lead to data races. "
sure, but are data races UB or are they handled gracefully (Java does the latter, AFAIK the same goes for C#)?
@RalfJ did you ever answer this question to your satisfaction?
I was pointed at this part of the Go docs:
When multiple goroutines access a shared variable v, they must use synchronization events to establish happens-before conditions that ensure reads observe the desired writes.
My conclusion is that data races in Go are UB, and that "Go is a safe language" is imprecise at best. One could also say it's really good marketing...
@RalfJ This Reddit comment from a "Go compiler engineer" seems to agree with that assessment. There are other users in that thread stating the same thing as well.
Thanks for the pointer!
I also got confirmation from a former Uber engineer that Swift has exactly the same issue -- they are compiling code assuming no data races, and if there are data races, arbitrary things can go wrong