There is a simple flowchart pertaining to data races: First question: Does your program have a data race? If no, everything is perfect. If yes, read on. Second question: Does your program have a performance problem? If no, then fix the race! If yes, then read on. Third question: There is no third question, fix the race!
The best way to go at these kinds of problems is to make a concurrently correct solution first, and then measure. Unless the penalty of locking is severe to your platform, don't even worry about fixing stuff. If the penalty of locking is too high, try to rethink your programs structure so it avoids the locking first. Only then, when you don't have a good solution without synchronization should you start looking at clever atomic update solutions in my opinion. The reason is that they tend to hide errors and they tend to be more brittle when moving to other architectures etc. So it is usually a last-resort effort. Or, it is the case from here, where you are carefully considering your options in the runtime because making things faster at this level helps everyone write faster (and correct!) programs. On Mon, Apr 16, 2018 at 3:00 PM <jake6...@gmail.com> wrote: > On Monday, April 16, 2018 at 7:08:27 AM UTC-4, Jesper Louis Andersen wrote: > >> On Sat, Apr 14, 2018 at 7:02 PM Penguin Enormous <kimkh...@gmail.com> >> wrote: >> >>> But looking at your answer, I see that you may imply certain race >>> conditions are allowed. Could you explain a bit more on that? Aren't race >>> conditions supposedly bad? >>> >>> Race conditions can, in certain cases, be benign if guarded properly by >> some other code. As long as you eventually solve the race in a valid way. >> > > A little OT, but to avoid confusion for other readers, I want to point out > that "logic race conditions" can be benign, but that "data race conditions" > should never be considered benign *in user code*. By a "data race > condition", I mean that two threads (or goroutines) are accessing the same > data at the same time, and one of the accesses is a write. > > I am not trying to imply that Jesper was saying any different. I just > wanted to clarify for others who could misinterpret his comments. > > -- > 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. > -- 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.
