Introduction

• You are free to use the book algorithm (which was presented in class) or any version of the algorithm you might find.
• You cannot use busy waiting.
• You are to use your semaphore wrappers to provide necessary semaphores.
• You are to use Solaris shared memory. See below about wrapping these calls in a class or wrapper.
• You are to collaborate in groups of two Again, we will NOT assign partners. Each of you is to write your own code, but use your partner to help debug and test your solution. This means that you MUST contact your partner first prior to sending help requests to the graders or tutors or CS staff. Indicate your partner in your code comments.
• Each philosopher must keep a count of the number of times he has eaten.
• When each philosopher has eaten the maximum number of times (max provided as an input parameter) the philosopher stops eating (his process dies).
• The time period for each eating session is an input parameter (fixed for all philosophers).

While Dining Philosophers is a neat problem, as written no one knows what the heck is going on. Thus you MUST have another process, the waiter, who monitors the philosophers' table. Because he wants to get a good tip, every 2 seconds the Waiter looks at the table and determines what is going on. He prints this data in a horizontal ``Santillo'' format:

• Printout #
• The current values in the state table for each philosopher, e.g., hungry (H), thinking (T), eating (E), or done (D).
• How many philosophers are thinking.
• How many philosophers are hungry.
• How many philosophers are eating.
• How many philosophers remain at the table.

Termination

When all the philosophers are done eating the Waiter prints out one more time and the program dies.

Input Parameters

There are 4 parameters to the program (in order). If all parameters are omitted, default values must be used.

• How many philosophers are coming to dinner. Defaults to 5.
• How long (in seconds) each philosopher eats. Defaults to 6.
• How many times each philosopher eats. Defaults to 4.
• How long (in seconds) each philosopher thinks. Defaults to 3.

Implementation Notes:

• You are to use your C or C++ wrapper/class to handle the management of semaphores.
• You are to create a C or C++ wrapper/class to handle the management of shared memory. This wrapper/class should have at a minimum operations to create, attach, detach, and destroy, shared memory. You can view this wrapper/class as a reasonable interface to the unreasonable interface provided by the operating system.
• Note the word class is used here as an abstraction. You do NOT have to create true C++ classes (although may find it useful to do so).

Stuff You Need to Turn In or Submit:

What to Turn In:

• A partial program listing showing:
  • The introductory comment that documents the program (see below).
  • Listings of your classes for support semaphore and shared-memory support. We want both the header files and the actual code.
    I say class in a very abstract way; both of these can be true C++ classes, but they can also be implemented via a set of wrapper functions. The key point is that you are to choose a way to wrap the system calls for semaphores and shared memory in a way that makes them easy to use, e.g., something like up(semid) should up a semaphore.

  Your introductory comment should be complete and detailed (like a README file), and should include the following information:

  • An overall description of your implementation (1 to 2 pages).
  • The identity of your partner.
  • How long overall it took to write the algorithm, to write the code, and to debug and to make it work.
  • The number of semaphores and the use of each semaphore.
  • A description of how you manage your processes, e.g., something about how you manage your main program, the Waiter, etc. Make sure to include comments about how you terminate and how you determine termination of your processes.
• One or two sample runs with the default input values. There will be additional input values, which will be used in demonstrating your program.
• We do NOT want a copy of your full program listing!!!!!

Where to Turn In:

What to Submit:

References:

• Solaris man pages for fork, semctl, and shmctl
• Chapter 3, UNIX Network Programming, W. Richard Stevens. On reserve in the library.
• Semaphore and shared memory tutorial.
• Philosophers FAQ.
• If you find other good references, please let me know.

Notes:

If you decide to NOT implement shared memory with a dynamically sized array, then use a maximum size of 10 philosophers, but expect to lose 4 points. You MUST also indicate this choice in the documentation comments at the front of your program.

We reserve the right to change the problem statement when someone demonstrates the ambiguity of said problem statement.

As usual, if your program was invoked incorrectly (wrong number of arguments, invalid arguments, etc.) then it should produce a usage message on cerr and exit with nonzero status. The usage message should also specify the defaults for all parameters.