MutexCondition Variable

Ian Collins

Threads are serialized, but timeslicing and blocking behavior tends to "mix things up", statistically speaking, far more than you apparently might think.

In fact we found in development of the OpenVMS-Tru64 UNIX thread library that there were very few multiprocessor races that couldn't be reproduced on a uniprocessor if you exercised it intensively and-or ran a long time. A few were certainly INCONVENIENT to reproduce, but far from impossible. An single instruction race window WILL be hit in uniprocessor testing if you're even moderately serious about it.

We also learned that if a race condition that couldn't be identified because it couldn't be reliably reproduced on a wide multiprocessor were left in shipping code it would be frequently and widely reproduced immediately -- even on uniprocessors -- by customers on the verge of multinational production system software rollouts. (Actually, that's a corollary: many races CANNOT be reliably reproduced on alpha or beta software, only on identical software installed by a large customer off official distribution media in a major production project.)

Nevertheless, if you want to develop and exercise threaded code, you need a multiprocessor. The wider the better; but 2 cores is far more than twice as good as one. To find bugs during development you don't want to have to run extended saturation test loads -- or wade through the data gathered during such a run to figure out what happened.