Your opinion regarded Go Race Detector

Hi folks! Recently, I’ve started to write code related to token updates. One chunk of my code in Goroutine is setting the value, and another one is reading it. Obviously, I saw race (the same example from the official docs), which was also detected by go run -race .. But I’m wondering, what’s the point? I mean, for example, the old token lives for 3 hours, and the new one appears after 1 hour, so is it critical to fix this issue? I’ve already applied using sync/atomic, but for me, it’s no sense. Could you explain this situation to me?

Speaking about the example, it shows the concurrent access to a map. As go.dev states, maps are not save for concurrent usage at all and it was the conscious decision. If you decided to store your tokens in map type, then the way to guarantee save code execution is to wrap it with mutex, wait group or atomic. From the practical point of view, if you are sure that there will never be a situation when your program will concurrently read from and write to your map, then of course you can leave it as it is. But it’s always valuable to foresee possible problems and fix them from the start. It gives you deeper understanding of the language and how things work beneath the surface.

1 Like