CS 110, Architecture and Operating Systems
Semaphores Project, Version 1.00
Due Date
This project is due Friday, February 22, 2002, at 9 P.M.
20 Points
Project Description
You are to expand on your fork program to have the
parent controlled by the child.
After forking the child, the parent:
    -  Prints out its PID,
    
 -  Prints out the child's PID,
    
 -  Sleeps for 2 seconds,
    
 -  After the sleep is  done, waits on an event (semaphore)
    
 -  Upon receiving the event, prints out the time,
    
 -  Updates a semaphore indicating that it is exiting,
    and
    
 -  Dies.
 
Once started, the child:
    -  Sleeps for 1 second,
    
 -  Prints out its PID,
    
 -  Prints out the parent's PID,
    
 -  Signals the event,
    
 -  Sleeps for 3 seconds,
    
 -  After the sleep is done, prints out the time,
    
 -  Waits for the parent to die,
    and
    
 -  Dies.
 
Stuff you NEED to Know and Do
    -  You cannot use busy waiting.
    
 -  You are to use Solaris-style semaphores.  See below about
	wrapping these calls in a
	class
	or
	wrapper.
	Most of the documentation on semaphores is in the manual
	pages (
man semget, man semctl, and
	man semop.  You also need to know about man
	ftok.  You can also find useful resources on semaphores
	by searching the Web; for example,
	Google helped me find
	a
	good page by Steven Hayes that has some sample code.
	(However, the use of ~/.cshrc in the
	ftok call is something that should not be imitated.)
     -  You are to collaborate in groups of two.
	We will NOT assign partners,
	find someone who is willing to discuss the project,
	your code, etc.
	Of course,
	each of you
	is to write your own code.
	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.
    
 -  Before you try to test your program, be sure to run the
	command "
stty -tostop" so that the child will be
	allowed to output to your terminal. Most of you will have
	this setting by default, but it doesn't hurt to set it again.
 
Stuff You Need to Turn In or Submit
    - 
    Turn in (in the bin outside Geoff's office):
    
	-  A printed copy of your commented program,
	and
	
 -  A script file of its execution.
    
 
    We do NOT need your Makefile in the printed submission.
    
    
 - 
    Submit
    
	-  Submit your source code by running 'cs110submit'
	    This is Project  02.
	    Your Makefiles must be included in the submission.
    
 
 
    -  You are to create a C or C++ wrapper/class to handle the
	management of semaphores.
	This wrapper/class should have at a minimum operations to
	create,
	set,
	delete,
	up
	and
	down
	a semaphore. 
	You can view this wrapper/class as a reasonable interface to
	the unreasonable
	interface provided by the OS system calls.
	Of course, you can (and should) create additional routines,
	e.g.,
	print.
    
 -  Note that the word class is used here as an abstraction.
	You do NOT have to create true C++ classes.
	Rather you can create your own library,
	each routine of which makes the actual system calls.
	However, we strongly encourage you to create a proper C++
	class because it will make your life easier in future projects.
 
Semaphore Notes
Turing
has only a certain number of semaphores.
They get eaten up unless they are properly freed when your
program terminates.
You can use
ipcs to see what semaphores are available, but it will
only show ones that are yours, or are group or world
readable.
Thus, using
0644 | IPC_CREAT for the third argument of
semget
helps in determining who has all the semaphores.
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.
If you end up with hidden semaphores that the CS Staff must
remove, you will lose points.
Returning Semaphores to the System:
    -  From inside a program,
	you can use
	
semctl(semid, 0, IPC_RMID, 0);
	to free all semaphores in
	the group identified by
	semid.
	This is the correct way to handle semaphores, and you will
	lose points if your program doesn't do it that way.
	An excellent way to make sure IPC_RMID is called
	is to put it into your destructor.
	
	Unfortunately, during debugging your program may crash before
	it gets to the destructor.  In that case, you'll need to get
	rid of your semaphores by hand.
    
 -  At the command level
	you can explicitly free semaphores
	by using
	
ipcrm.
     -  The Turing command 
removeipc (it lives in
	/usr/local/share/bin) will get rid of all
	semaphores, shared memory, and other IPC resources that you
	own.  It is your friend.  Use it a lot.
     -  A short shell script to remove all your semaphores:
#!/bin/sh
ipcs | egrep YourUserName | awk '{print $2}' | xargs -n1 ipcrm -s;
ipcs | egrep YourUserName | awk '{print $1}' | xargs -n1 ipcrm -s
     -  A short perl script to remove all your semaphores
	and shared memory
	(save it in an executable file,
	your UID is an argument):
#!/usr/local/bin/perl
$username = shift(@ARGV);
@output = `ipcs | grep $username | cut -c1-12`;
foreach (@output)
{
     chop;
     print `ipcrm -$_`;
}
    
 
Last modified February 16, 2002, by geoff@cs.hmc.edu