CS 110 Intro to Computer Systems
Basic Barber Shop Project - Version 1.0
Due 16 November, 9PM


Each of you is to implement a robust variation of the Barber Shop problem using the UNIX fork command and mutual exclusion techniques (use your partner for design and code review). This Barber Shop is on a military reservation, so there are 3 categories of people needing haircuts - Officers, NonComs, and Grunts. You are to use a Producer/Consumer paradigm with shared circular buffer.


Your Producer, a fat old Sergeant, is a process that periodically attempts to add a new person, long hair, to the buffer of chairs in the Barber shop. By periodically is meant that the Producer uses the sleep call with a sleep time determined by a command line input parameter between 1 and 5 seconds (default 3). If there are no open seats, then the Sergeant waits until there is an empty chair.


The Producer and Consumer share a buffer of 20 chairs, but there are 3 FIFO lists within the 20 chairs. At any time there may be only 20 people in the Barber Shop chairs with a random distribution of Officers, NonComs, and Grunts, and 1 person getting a hair cut. Note: if there is only one type of person in the Barber Shop, then the shop queue acts as a circular buffer.


Your Consumer process is the Barber, a wiry old private. Haircuts have an individual time between 1 and 5 seconds, determined by the input. But priority for service is instituted - Officers get priority over anyone else, followed by NonComs, followed by grunts.


  1. You should use a file containing random sleep times (integers between 01 and 05 for grunts, between 11 and 15 for NonComs, and between 21 and 25 for Officers) to drive your Producer process:
    • the first digit provides the food chain position
    • the second digit provides the time for a haircut
    An example file can be found on the course web page
  2. You MUST use a circular buffer as the barber shop; it is true that the buffer only behaves circular when there are only 1 category of long hair.
  3. In grading we will use multiple files to drive your programs. You do not have to open a particular input file name; instead just use <, i.e., shell redirection of input.
  4. You MUST manage the Barber Shop wait area as priority FIFO queues. People DO NOT move to new chairs, rather through list management, the Producer and Consumer know the next chair, i.e., person to get their hair cut or an empty chair in the Barber Shop that can be added to one of the 3 lists.
  5. The Sergeant, the Producer, MUST also manage the wait area outside the Barber Shop. He cannot let someone in unless there is a chair in the Barber Shop (thus, he is in a loop that keeps trying to read input and put a person in the Barber Shop). Each time he awakes (time defaults to 3, but is a startup parameter), he checks his waiting area (input stream) and, he will seat the next person (only 1 person per wakeup) (a officer, noncom, or grunt) as long as there is room in the Barber Shop, otherwise he waits (blocks - NO BUSY WAITING) for such space.
  6. Assume that you DO NOT have a pointer datatype for the Barber Shop. Use an array with a MAX_SIZE of 20 and implement an array version of a linked list for the Barber Shop waiting area. You can either keep the list heads in the array or as separate variables.
  7. While this is a neat problem, as written no one knows what the heck is going on. Thus you MUST have another process, the Lieutenant, who monitors the overall Barber Shop. Because he is young and stupid, every 2 seconds the Lieutenant pokes his head into the Barber Shop to determine:
    • Total number of Officers that have entered the system.
    • How many Officers are waiting in the Barber Shop.
    • How many Officers have gotten their hair cut.
    • Total number of NonComs that have entered the system.
    • How many NonComs are waiting in the Barber Shop.
    • How many NonComs have gotten their hair cut.
    • Total number of Grunts that have entered the system.
    • How many Grunts are waiting in the Barber Shop.
    • How many Grunts have gotten their hair cut.
    • Total number of empty chairs.
    • Total number of occupied chairs.
    • Who is in the Barber Chair - Officer, NonCom, or Grunt.
    • The Lieutenant numbers each output sequentially (easier to watch the time fly).
    • Possible output also includes the 3 queues (everyone in the queue, their chair number, etc.) - see discussion of parameters.
    An example printout will be posted real soon. You are to Match the posted format in your output.
  8. Termination. When the input file is empty, the Sergeant terminates, but the Barber continues until the last long hair has had his hair cut and the Lieutenant continues until both the Sergeant and Barber have terminated. Look at some of the semaphore operations for ways to do this. Thus, the final output from the Lieutenant should show an equal number of long hairs entering the system and short hairs produced with an empty waiting room.
  9. There are 3 parameters to the program:
    1. Parameter 1 - How long (in seconds) the Consumer process should sleep before starting, default = 1, i.e., time it takes Barber to have coffee. This means that the Producer (Sergeant) is running, but the Consumer has not yet started.
    2. Parameter 2 - Used to determine if the Barber Shop contents (the queue) should be printed out by the Monitor/Lieutenant (print entire circular buffer in addition to normal printout: default = 0, no print). An example will be posted. You are to Match the posted format in your output.
    3. Parameter 3 - How long the Producer should sleep between each search of the wait area, default = 3.
  10. Semaphore Notes:

    Turing has only a certain amount of semaphores. They get eaten up unless they are freed when your program terminates. You can use ipcs to see what semaphores are being used, but it will only show ones which are yours, or are group or world readable. Thus using 0664 | IPC_CREAT for the third arg of semget helps in determining who has all the semaphores and also helps in removing semaphores that you have left around.
    At the command level you can free semaphores by using ipcrm -s. You lose points for holding old semaphores and/or shared memory!!!
    Use removeipc to remove all your shared memory and semaphores if things get a little too messy.
    From inside a program, you can use semctl(semid, 0, IPC_RMID, 0); to free all semaphores in the group identified by semid.
    Using 0 for the key means that the semaphore will be private to a single process and will not be seen by other processes, so don't do that.

    Due Dates:

    16 November, 9PM

    What to Turn-In:

    • Submit your code in the usual way, using submit
    • NO HARDCOPY CODE is desired or wanted
    • A HARDCOPY Intro program comment that describes your overall implementation:
      • including the number of semaphores and the use of each semaphore,
      • your use of shared memory (e.g., some counts may be in shared memory or in semaphores), a commented struct definition is required!!
      • your algorithm for the 3 lists; how you manage the 3 Barber Shop queues, including how you arranged the shared memory, e.g., a struct with comments on contents, links, etc, is required!!!
      • your algorithm for the child processes determining that they are done (not just a momentary lull in people entering the Barber Shop).
    • A paragraph how your program relates to scheduling and/or virtual memory management in an operating system (this is not just a coding project :-) think about relationships with fixed size memory areas, priorities, etc. )
    • Your comments need to be complete and detailed!!!
    • A listing of a run against the input that is posted on the web page.
    • After 16 November, I will release a grade sheet which will have some other input sequences. You will then run your unchanged program against those new inputs and turn-in the related runs. When posted the grade sheet will tell all.

    Where to Turn-In:

    To the plastic bin outside Professor Erlinger's office.


    • Solaris man pages for fork, semctl, and shmctl
    • Chapter 3, UNIX Network Programming, W. Richard Stevens. On reserve in the library.
    • http://www.yggdrasil.com/bible/info-html/ipc.html
    • If you find other good references, please let me know.


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

    Last modified Nov 9, 01 by mike@cs.hmc.edu