CS444 hw4: Semaphore system calls for Tiny UNIX

Provide a README with guide to your sources.  You may do this assignment with a partner. Note your partner in README, and provide the solution in one of the partner's hw4 directory.

Implement the simplified semaphore syscall service:

      semid = sem_create(init_count)

      down(semid)

      up(semid)

      sem_delete(semid)

Make the process block when waiting on a semaphore.  Use FIFO among the waiting processes, or explain what other scheme you are using.  The same queue package we used before, modified for holding ints instead of chars, is provided in subdirectory "intqueue".

As with the sleep system call, the twakeup call is not directly useful.  An up system call should only unblock one process, or none at all. Note that the hw3 solution has twakeup_one(pid).

The provided makefile works the same way as hw3's did. Use

  make U=testmutex   

to make testmutex.lnx from testmutex1.c, testmutex2.c and testmutex3.c

The user level program prodcons[123].c is supplied, doing the classic producer-consumer program.  It uses an intqueue for the shared buffer between the producer and consumer. A simpler user test program trio using only mutex is provided in testmutex[123].c.

Note the debuglog facility.  You can use this to track events in your semaphore service without disturbing the timing with output.  In particular, add little reports such as "up(0:1)" to mark an up that makes sem 0's count reach 1.

1. Write semaphore.h and a trivial semaphore.c that just prints out "UP"  "DOWN", etc. (caps for kernel actions, say) when the kernel methods are called. Add semaphore.c/h/opc to the makefile. Edit ulib.s, tunix.c, etc., to add the new system calls. Take out the comment markers in testmutex.c and get it built. See it run and fail to actually do mutual exclusion: it will show A and B both requesting mutex and obtaining mutex, then a little later both releasing mutex.  What we want to see is one (probably A) obtaining mutex, whereas B requests but does not obtain mutex, then A sleeping for .5 sec, then releasing mutex, at which point B gets the mutex, sleeps, and releases it.

2. Implement the semaphore calls and get testmutex working. Then get prodcons working. 

3. Finally, modify testmutex to have main1 join the group trying to use the mutex, after creating the mutex and then doing a 50-ms sleep so that all three processes start trying to get the mutex nearly at once.  Call this test2mutex[123].c. main1 can output "C requests mutex" and "C has mutex".

4. Optionally, make the scheduler preemptive. The tick handler can count down a process's quantum (a new data member of PEntry), and when it's exhausted, call scheduler().  If you do this, please note it in README.

For collection:

README--authorship, late days if needed

tsystm.h—needs new prototypes for calling from tunix to semaphore

tunix.c, ulib.s,tsyscall.h —new syscalls

semaphore.[ch]—semaphore service