CS 110 Intro to Computer Systems
Basic Barber Shop Project - Version 1.0
Due 16 November, 9PM
Introduction
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.
-
Mutual exclusion is to be provided
by Solaris semaphores (see semctl).
-
Shared buffer provided by
Solaris shared memory (see shmctl)
Producer
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.
Buffer
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.
Consumer
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.
Notes:
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
There are 3 parameters to the program:
-
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.
-
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.
-
Parameter 3 -
How long the Producer should sleep between
each search of the wait area,
default = 3.
-
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.
References:
-
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.
Notes:
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