• Take 3: Much of the program stays the same, but there are some new global variables, and the implementations of waitForPermission and grantPermission ar changed. You can click here to see the full program.
• The code below summarizes what's different in take 3:

static mutex forks[kNumForks];
static int numAllowed = kNumForks - 1;
static mutex m;
static condition_variable_any cv;

static void waitForPermission() {
  lock_guard<mutex> lg(m);
  cv.wait(m, []{ return numAllowed > 0; });
  numAllowed--;
}

static void grantPermission() {
  lock_guard<mutex> lg(m);
  numAllowed++;
  if (numAllowed == 1) cv.notify_all();
}

• For the moment, forget about the mutex called m and focus on the condition_variable_any called cv.
• The condition_variable_any is the core concurrency directive that can preempt and block a thread until some condition is met.
  • In this example, the philosopher seeking permission to eat waits indefinitely until some condition holds (unless the condition holds already, at which point it doesn't need to wait).
    • If numAllowed is positive at the moment wait is called, then it returns immediately without blocking.
    • If numAllowed is zero at the moment wait is called, then the calling thread is pulled off the processor, marked as unrunnable and blocked until the thread manager is informed (by another thread) that the value of numAllowed has changed.
  • In this example, the philosopher just finishing up a meal increments numAllowed, and if the value of numAllowed goes from 0 to 1, the same philosopher signals (via notify_all) all threads blocked on the condition_variable_any that a meaningful update has occurred. That prompts the thread manager to reexamine the condition on behalf of all threads blocked by wait, and potentially allow one or more of them to emerge from their long nap and move on to the work they weren't allowed to move on to before.

• Here's the code again:

static mutex forks[kNumForks];
static int numAllowed = kNumForks - 1;
static mutex m;
static condition_variable_any cv;

static void waitForPermission() {
  lock_guard<mutex> lg(m);
  cv.wait(m, []{ return numAllowed > 0; });
  numAllowed--;
}

static void grantPermission() {
  lock_guard<mutex> lg(m);
  numAllowed++;
  if (numAllowed == 1) cv.notify_all();
}

• Because numAllowed is being examined and potentially changed concurrently by many threads, and because a condition framed in terms of it (that is, numAllowed > 0) influences whether a thread blocks or continues uninterrupted, we need a traditional mutex here so that competing threads can lock down exclusive access to all things numAllowed.
• The lock_guard class exists to automate the locking and unlocking of a mutex.
  • The lock_guard constructor binds an internal reference to the supplied mutex and calls lock on it (blocking—within the constructor—until the lock can be acquired).
  • The lock_guard destructor releases the lock on the same mutex.
  • The overall effect—at least in the above two functions—is that the combination of both implementations is marked as one big critical region.
    • Java gurus: the lock_guard class is the best thing C++ has in place to emulate Java's synchronized keyword.
  • The lock_guard is a template, because its implementation only requires its template type respond to zero-argument lock and unlock methods. The mutex class certainly does that, but many others (e.g. C++11's recursive_mutex, or its timed_mutex) do as well, and the lock_guard didn't want to hard code in mutex.
• condition_variable_any::wait requires a mutex be supplied to help manage its synchronization on the supplied condition.
• If condition_variable_any::wait notices that the supplied condition isn't being met, it puts the current thread to sleep indefinitely and releases the supplied mutex. When the condition_variable_any is notified and a waiting thread is permitted to continue, the thread re-acquires the mutex it released just prior to sleeping.