Update dining philosophers project for multicore systems

[Max-Hailperin]

The dining philosophers Exploration Project, 4.2., says "Depending on how fast your system is, you may need to change the number 100000. The program should initially print out messages, at a rate that is not overwhelmingly fast, but that keeps you aware the program is running. With any luck, after a while, the messages should stop entirely."

That was written in the days of single-core processors. Nowadays, everyone runs a multicore processor and the deadlock tends to happen so rapidly that no output messages are seen at all prior to the deadlock unless the number is substantially reduced. This is not because the program is running faster but because it is running with the threads much more aggressively interleaved.

The text should be updated to point this out and to suggest comparing the rapidity of deadlock with the program running normally (on multiple cores) vs. constrained to run on a single core. (The difference should be much more than the factor of 2 or 4 that could be explained by the speedup achieved by using 2 or 4 cores.)

On Linux systems, a program can be run on a single core using schedtool as shown in Exploration Project 3.3. On OS X systems, the Xcode package contains an Instrument app that can be used for this, or there is a way of globally setting the number of cores that will be used (which takes effect upon rebooting):
sudo nvram boot-args="cpus=1"
and then to eliminate this restriction (again, with a reboot to put it into effect)
sudo nvram boot-args=""

I would guess that there is a way for Windows too.