Programming Perl, 4th Edition

Handling Race Conditions

Which runs us right into the topic of race conditions. What are they really? Race conditions turn up frequently in security discussions. (Although less often than they turn up in insecure programs. Unfortunately.) That’s because they’re a fertile source of subtle programming errors, and such errors can often be turned into security exploits (the polite term for screwing up someone’s security). A race condition exists when the result of several interrelated events depends on the ordering of those events, but that order cannot be guaranteed due to nondeterministic timing effects. Each event races to be the first one done, and the final state of the system is anybody’s guess.

Imagine you have one process overwriting an existing file and another process reading that same file. You can’t predict whether you read in old data, new data, or a haphazard mixture of the two. You can’t even know whether you’ve read all the data. The reader could have won the race to the end of the file and quit. Meanwhile, if the writer kept going after the reader hit end-of-file, the file would grow past where the reader stopped reading, and the reader would never know it.

Here the solution is simple: just have both parties flock the file. The reader typically requests a shared lock, and the writer typically requests an exclusive one. So long as all parties request and respect these advisory locks, reads and writes cannot be interleaved, and there’s no chance of mutilated data. See the ...