The Ars Technica article explains it better than I ever could, but here goes:
The Mac OS kernel has services like disk storage and networking access which have to be provided by a queueing mechanism. Only one running program can be allowed to read or write to the disk at one time, and only one can be allowed to send or receive data on the ethernet at once. A program writing to disk is granted access and locks the disk access service, preventing other programs from accessing the disk until it has finished. It then unlocks the disk access service and the next program is granted access. On Panther the whole disk access subsystem is considered a single resource that must be locked while in use.
Civ3 runs several programs concurrently. One is the actual game program that you interact with directly. Another is the audio soundtrack which Civ3 kicks off by asking Quicktime to play sounds. Quicktime has to read disk files in order to produce the sound effects. Civ3 also has to read and write disk files in order to get the graphics that it displays, and when it wants to create an autosave, for example. If there are two CPUs then the Civ3 game may be running on one and the Quicktime sound track on the other. The kernel will see these as two programs competing for disk access.
Still with me? So far I think I've described a set of facts. Now I'm going to speculate:
Let's imagine that Civ3 tells Quicktime "Play a sound file, and tell me when you've finished". It then starts to create an autosave. Quicktime acquires a lock on the disk system from the kernel in order to read the music file. Civ3 is locked out of the file system and can't proceed with writing the Autosave. Civ3 is busy, so when Quicktime calls back to say "Done that, what next?" Civ3 can't hear. Eventually something (probably Quicktime) gets fed up with waiting and times out, releasing the disk access lock. Civ3 can then write its file and life can continue.
The grid-lock I've described is known in the trade as a "deadly embrace" where two programs are both waiting for each other to finish before they can continue. I have no idea whether there are actually such opportunities in Civ3, but if they do exist then multiple processors will make them much more likely to be a problem, as a single processor already sequences the programs that it's running, reducing the chances of concurrent requests for the same resources.
Fast forward to Tiger. Tiger doesn't use a single lock for the entire disk access process when a program wants to use it. It only locks the bits of file access that the program needs at the time. This means programs that know better will only ask for exclusive locked access to the component they need, then release that lock and acquire a lock for the next piece. Quicktime is undoubtedly one such program. In my speculative scenario above this would mean that Quicktime would never lock up the whole file system on Tiger, Civ3 would be able to get in and do its autosave, and the software would not hang.
).
