On Saturday, March 17, 2018 at 10:37:48 AM UTC-4, matthe...@gmail.com wrote: > > I think the second example alternative given (playground link above) has a >> data race? > > > I’m not surprised that the race detector sees something (a read can happen > during a write of the checked bool) but I don’t think this could actually > cause problems because the var’s memory value will always be 0 or 1. >
> There may be implementation details or future implementation details that > cause a problem though, so one option could be to protect the bool as a > shared resource with a mutex or equivalent, but I think rog’s solution is > better anyway (the first one). > +1. At this point, I would like to pull out the classic blog post: Benign data races: what could possibly go wrong? <https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong> I would put this in the list of articles every programmer should read. In part because it is so very tempting to cut corners when you "know that it will work". And it may, on your architecture, with the current compiler. But even if it does it could silently break later. There is no such thing as a safe race in user code. Respect - Jake -- 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. For more options, visit https://groups.google.com/d/optout.
