Don't try to account for race conditions. Eliminate them. Prevent them.
Ever see a delay added to code to account for a race condition? At least two bad things can happen, and it's not either/or. 1/
Ever see a delay added to code to account for a race condition? At least two bad things can happen, and it's not either/or. 1/
The first risk is that the delay might not be long enough. Or it might be long enough most of the time. Or for now, until something changes. Even after adding a delay, it's still a race condition. You've still got the same problem. 2/
The second risk is that some or all of the time the delay is longer than needed or entirely unnecessary. After all, the length of the delay is usually a guess. Guess too little and the risk of the race causing a problem remains. 3/
Guess too long and you're delaying something for no reason.
Real example: I've seen 500ms, even 1000ms delays added to execution of scripts on web pages to make sure that some other script or request has finished. 4/
Real example: I've seen 500ms, even 1000ms delays added to execution of scripts on web pages to make sure that some other script or request has finished. 4/
That delay is there because the race condition causes a failure sometimes. Most of the time it just causes all or part of the page to load slower. And yet the original problem the delay was added to solve wasn't completely eliminated. 5/
So what do we do? Make the delay a little longer, slowing things down even though most of the time we don't need to, yet still never eliminating the risk? That's terrible. We should never do that. 6/
Look for other solutions. There's always another way. If things need to happen in a particular sequence, express that in the code. When practical, don't attempt to do something until you know the application is in a state that permits it. 7/7
