• that there are never any race conditions, no matter how remote the chances are, and...
• that there's no possibility of deadlock, lest a subset of threads are blocked forever and starve for processor time.

• We could, for instance, recognize that it's impossible for three or more philosophers to be eating at the same time, via a simple pigeonhole principle argument (e.g. three philosophers can be eating at the same time if and only if there are six forks, and there are not). We can, therefore, limit the number of philosophers grabbing forks to 2.
• We can also argue that it's okay to let up to four (but not all five) philosophers to transition into the eat portion of their think-eat cycle, knowing that at least one will succeed in grabbing both forks.

Here's the core of a program that takes the second approach (click here for full program):

static const unsigned int kNumPhilosophers = 5;
static const unsigned int kNumForks = kNumPhilosophers;
static const unsigned int kNumMeals = 3;
static mutex forks[kNumForks]; 
static unsigned int numAllowed = kNumPhilosophers - 1; // impose limit to avoid deadlock
static mutex numAllowedLock;

static void think(unsigned int id) {
  cout << oslock << id << " starts thinking." << endl << osunlock;
  sleep_for(getThinkTime());
  cout << oslock << id << " all done thinking. " << endl << osunlock;
}

static void waitForPermission() {
  while (true) {
    numAllowedLock.lock();
    if (numAllowed > 0) break;
    numAllowedLock.unlock();
    sleep_for(10);
  }
  numAllowed--;
  numAllowedLock.unlock();
}

static void grantPermission() {
  numAllowedLock.lock();
  numAllowed++;
  numAllowedLock.unlock();
}

static void eat(unsigned int id) {
  unsigned int left = id;
  unsigned int right = (id + 1) % kNumForks;
  waitForPermission();
  forks[left].lock();
  forks[right].lock();
  cout << oslock << id << " starts eating om nom nom nom." << endl << osunlock;
  sleep_for(getEatTime());
  cout << oslock << id << " all done eating." << endl << osunlock;
  grantPermission();
  forks[left].unlock();
  forks[right].unlock();
}    

• The program on the previous slide always works, because there's no way all five philosophers can be mutually blocked at the same instant. We only allow four to go on and grab forks.
• It does, however, have one design flaw, and we'll discuss that design flaw as a means for coming up with an even better solution.

• The solution uses busy waiting, which in the eyes of systems programmers is usually a big no-no unless you have no other options.
• To see what I mean, focus in on the implementation of waitForPermission:

static void waitForPermission() {
  while (true) {
    numAllowedLock.lock();
    if (numAllowed > 0) break;
    numAllowedLock.unlock();
    sleep_for(10);
  }
  numAllowed--;
  numAllowedLock.unlock();
}

• The narrative is pretty straightforward: Continually poll the value of numAllowed until the value is positive. At that point, decrement it to emulate the consumption of a shared resource—in this case, a permission slip allowing a philosopher to start grabbing forks. Since there are multiple threads potentially examining and decrementing numAllowed, identify the critical region as one that needs to be guarded by a mutex. And if the philosopher notices the value of numAllowed is 0 (e.g. all permissions slips are out), then release the lock and yield the processor to some other philosopher thread who can actually do some useful work.
• What's the outrage? The above solution uses busy waiting, which is concurrency jargon used when a thread periodically checks to see whether some condition has changed so it can move on to do more meaningful work. The problem with busy waiting, in most situations, is that it hoards the processor from time to time, when it would be better to ensure that other threads—those that presumably have meaningful work they can do—get the processor instead.
• A better solution: if a philosopher doesn't have permission to advance (e.g. numAllowed is atomically confirmed to be zero), then that thread should be put to sleep indefinitely until some other thread sees reason to wake it up. In this example, another philosopher thread, after it increments numAllowed within grantPermission, could notify the indefinitely blocked thread that some permissions slips are now available.
• Implementing this idea requires a more sophisticated concurrency directive that supports a different form of thread communication. Fortunately, C++11 provides a standard (albeit difficult-to-understand, imo) directive called the condition_variable_any.