Stream: general

Topic: Data Races in Go/Swift?


RalfJ (Nov 28 2019 at 14:42, on Zulip):

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?

RalfJ (Nov 28 2019 at 14:53, on Zulip):

I find it rather amusing (or concerning) that the Go memory model literally says nothing about data races...

Muhammad Mominul Huque (Dec 08 2019 at 12:23, on Zulip):

"The Swift language guarantees memory safety in single threaded environments. However, conflicting accesses in multithreaded code lead to data races. "
https://swift.org/blog/tsan-support-on-linux/

RalfJ (Dec 11 2019 at 15:29, on Zulip):

sure, but are data races UB or are they handled gracefully (Java does the latter, AFAIK the same goes for C#)?

Kyle Strand (Dec 19 2019 at 20:01, on Zulip):

@RalfJ did you ever answer this question to your satisfaction?

RalfJ (Dec 22 2019 at 13:15, on Zulip):

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...

Wesley Wiser (Jan 24 2020 at 19:45, on Zulip):

@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.

RalfJ (Jan 26 2020 at 16:59, on Zulip):

Thanks for the pointer!

RalfJ (Jan 26 2020 at 17:00, on Zulip):

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

Last update: Jan 28 2020 at 06:55UTC