A toy language for a toy race-condition finder.
Select an example configuration from the dropdown box, click "Run" to run either of the programs individually, or "Find Race Conditions" to compute all interleavings of the two programs and look for race conditions between them.
I wrote this because I feel race conditions are an underappreciated problem in software development. In programming education, they're often not given the attention they deserve, given that they are a real problem that comes up once you get into any kind of concurrent programming — and one that can very difficult to pinpoint, much less fix.
The general "someone else's problem"-ness surrounding race conditions seems to have fostered two misconceptions in particular that I wanted to highlight.
Even though Matchbox is an assembly-like language, race conditions are not restricted to machine language. Nearly every high-level programmer works with either filesystems or databases, and those are both basically gigantic tracts of shared memory. Race conditions are just waiting to happen, if you're not careful.
And there is sometimes the impression that the only way to protect oneself against race conditions is if the system provides an atomic-test-and-set-like operation. If such an operation is avaiable, you should probably use it, but it's not the only way. There are several different programming methods for guaranteeing mutually exclusive access to a resource, even when such operations are not available. These were developed before such operations were widely available in hardware, and although they are largely of historical interest, they also posess a certain conceptual beauty. One such method is Peterson's Algorithm, which Matchbox can run and show correct.