Last night I amused myself for a few minutes by posting in a thread on comp.lang.c that had drifted over to the motives behind the design of the near-ubiquitous QWERTY keyboard layout. I managed to relate the design choices to those in a multithreaded program. The article amused me enough that I enclose it verbatim below. If you're not a computer geek, don't bother continuing, because it won't make any sense.
Now, if there's only of these spokes in motion, there's no problem. But there's a mutual exclusion problem: if more than one of them is in motion at once, e.g., one going out and another coming back, then they'll hit one another and you'll have to take a moment to disentangle them by hand, which is annoying and possibly messy. It's a race condition that you will undoubtedly be bitten by quickly in real typing.
The problem is exacerbated if the letterforms for common digraphs have adjacent spokes. This is because the closer two spokes are, the easier they can hit one another: if the spokes are at opposite ends of the array, then they can only hit at the point where they converge at the cursor, but if they are adjacent then they'll hit as soon as they start moving.
One solution, of course, is to introduce serialization through use of locking: allow only one key to be depressed at a time. Unfortunately, that reduces parallelism, because many digraphs that you want to type in the real world do not have adjacent spokes, even if you just put the keys in alphabetical order.
The adopted solution, of using a QWERTY layout, is not a real solution to the problem. Instead, it reduces the chances of the race condition by putting keys for common digraphs, and therefore their spokes, far away from each other. You can still jam the mechanism and have to untangle the spokes, but it happens less often, at least for English text. This in fact helps you to type *faster*, not slower, because you don't have to stop so often to deal with jammed-together spokes.
To conclude: mechanical QWERTY typewriters are at the same time an example of optimization for the common case and inherently flawed because of the remaining race condition. This is a great example of a tradeoff that you should not make when you design a program!
[1] I don't know any of the proper vocabulary here. I was about 8 years old when I used the one we had at home, and it was thrown out as obsolete soon after.