Thread Safety - Java Concurrency in Practice - page 20

2.2.1. Race Conditions
UnsafeCountingFactorizer has several race conditions that make its results unreli-
able. A race condition occurs when the correctness of a computation depends on the relative
timing or interleaving of multiple threads by the runtime; in other words, when getting the
right answer relies on lucky timing. [4] The most common type of race condition is check-
then-act , where a potentially stale observation is used to make a decision on what to do next.
We often encounter race conditions in real life. Let's say you planned to meet a friend at noon
at the Starbucks on University Avenue. But when you get there, you realize there are two
Starbucks on University Avenue, and you're not sure which one you agreed to meet at. At
12:10, you don't see your friend at Starbucks A , so you walk over to Starbucks B to see if
he's there, but he isn't there either. There are a few possibilities: your friend is late and not at
either Starbucks; your friend arrived at Starbucks A after you left; or your friend was at Star-
bucks B , but went to look for you, and is now en route to Starbucks A . Let's assume the worst
and say it was the last possibility. Now it's 12:15, you've both been to both Starbucks, and
you're both wondering if you've been stood up. What do you do now? Go back to the other
Starbucks? How many times are you going to go back and forth? Unless you have agreed on
a protocol, you could both spend the day walking up and down University Avenue, frustrated
and undercaffeinated.
The problem with the “I'll just nip up the street and see if he's at the other one” approach
is that while you're walking up the street, your friend might have moved. You look around
Starbucks A , observe “he's not here”, and go looking for him. And you can do the same for
Starbucks B , but notatthesametime . It takes a few minutes to walk up the street, and during
those few minutes, the state of the system may have changed .
The Starbucks example illustrates a race condition because reaching the desired outcome
(meeting your friend) depends on the relative timing of events (when each of you arrives at
one Starbucks or the other, how long you wait there before switching, etc). The observation
that he is not at Starbucks A becomes potentially invalid as soon as you walk out the front
door; he could have come in through the back door and you wouldn't know. It is this inval-
idation of observations that characterizes most race conditions—using a potentially stale ob-
servation to make a decision or perform a computation. This type of race condition is called
check-then-act : you observe something to be true (file X doesn't exist) and then take action
based on that observation (create X ); but in fact the observation could have become invalid
between the time you observed it and the time you acted on it (someone else created X in the
meantime), causing a problem (unexpected exception, overwritten data, file corruption).