Business Lessons from Computer Science - Dining Philosophers

I think it's an important lesson that should be taught in any management curriculum as it encourages abstract thinking and problem solving.

This is essentially a lesson in efficient resource management which in Computer Science (and business) is of the upmost importance. It also happens to be one that is forgotten and/or fretted over far too often. In this lesson the student is given a problem that they need to solve with code. The problem sounds like a riddle and is set up with a couple rules.

Rules of the Dining Philosophers

- Five philosophers are sitting around a circular table with a big bowl of food in the center.

- Philosophers go between eating and deep thought at arbitrary times but never talk to each other.

- In between each philosopher is placed one chopstick, the philosophers need both chopsticks on either side of them in order to eat.

- They can pick up one chopstick at a time but will put both back on either side when finished.  

Here's a diagram:

for simplicity they will all be Plato

The challenge: Create some simple rules the philosophers can abide by to make sure nobody starves, they only eat when they want to and most importantly it's done in the most efficient manner possible.  

First: Throw out the rotate around the table in a circle approach. That's not efficient. It will slow your system/business down unnecessarily. Someone who is doing their job in a management role will not recognize this as an option.

The problem:

Do nothing, they'll work it out. Unfortunately this type of assuming is when things go very wrong in both business and computer science. With no rules it's possible the philosophers all get hungry at the same time and grab the left chopstick, they will then all get stuck. This is deadlock.

A simple example of this in business is when two groups want to use the conference room at the same time. They both scheduled it and now need a dispute resolution. It's up to the manager to make a decision and generally it means that one group will "starve".

The other problem is almost the opposite. Some philosophers are going back and forth between eating and not eating so often they constantly consume both the chopsticks next to them leaving the other 3 philosophers to starve. This is called livelock. In computer science this is the sort of thing that happens in a DDOS attack.

The best example of this in business I can think of is managing your time. Sometimes certain issues will be taking up so much time and back and forth that other ones that are just as important are falling by the way side.

In both of these cases a simple rule set is needed to prevent these situations. Programmers need to create them to manage their programs efficiently and business managers need to create them to make sure their businesses run efficiently. 

The solution:

The most common way programmers attack this problem is by crafting rules around what philosophers can and can't do and placing virtual markers on the chopsticks. There is actually a solution that can be derived from this but in general it's far more complicated than it's worth and it has a lot of moving parts.

The real answer lies in a programming paradigm called Semaphores. In computer science semaphores are great little pieces of code that are aware of the resources and what needs to and is consuming them. In the case of the dining philosophers. Sometimes these are also called state machines. In the example of the dining philosophers it acts as a waiter. All the philosophers need to do is report to the semaphore whether they are hungry or not and the semaphore will let them know when they can eat. It keeps track of whose hungry and simply releases the resources in an intelligent manner when available.

not a simple semaphore (courtesy of http://blog.friendseat.com/robot-waiters-replacing-human-waiters/ )

Some of the best policies a manager can put into place are actually simple semaphores. A lot of times these aren't the most obvious solutions and we end up running around just as programmers do trying to put a bunch of rules and actions behind things. To create a semaphore it's important to think in the abstract and view the problem as an outsider.     

In the simple case of conference room management a simple tool to have people reserve the conference room at certain times solves the problem. Same thing with managing time for different projects, it just takes a little planning and scheduling. From the outside it seems easy but that's exactly the importance of the lesson. Most of the time it takes a little zooming out to zoom in.