E-mail a copy of your modified JavaOS files complete with a journal to cop4610@cs.fsu.edu, by Wednesday, October 1st at 4 PM.
The method for emailing your solution is to create a uuencoded compressed tar image of only the files you changed. This way the grader can just uudecode, uncompress, and un-tar your files on top of an unmodified JavaOS source tree and your files will drop into place for easy grading. For example, assuming that you modified the files SOSSyscallIntHandler.java and AppTests.java, then you would turn in your assignment like this (substitute "tar" for "gnutar" if you are on a Linux machine):
cd
cd cop4610/P2
gnutar czvf ~/P2.tar.gz SOSSyscallIntHandler.java AppTests.java P2.journal
cd
uuencode P2.tar.gz < P2.tar.gz
| /usr/ucb/mail -s "P2 submission" cop4610@cs.fsu.edu
This project will be graded on a scale of 0-100.
The following steps will install an entire working copy of the JavaSOS simulator into your home directory and build the simulator from the source code. Notice that you probably already have a "cop4610" directory (or equivalent) so all these steps may not be necessary. Also notice that this assignment uses a different JavaSOS starting source file from the previous assignment.
cd mkdir cop4610 chmod 700 cop4610 cd cop4610 mkdir P2 chmod 700 P2 cd P2 gnutar xzvf ~jtbauer/jsosP2.tar.gz make
To run the simulator, do the following:
java SIM
The simulator will run as described in the Guide to the Java Version of SOS available in class and from the class home page. A text file named sim.out is created that contains all the trace messages from the simulation run.
Your assignment is in three parts. The first two deal with modifying the message queue IPC system within JavaSOS. The last part requires some investigative sleuthing within the source code to find and correct a race condition.
Modify JavaSOS as appropriate to solve problem 5.7 in the textbook (on page 170). The problem states: Modify the simple operating system to have two types of blocked states: BlockedOnDiskIO and BlockedOnReceive. Make sure the state always reflects the correct reason the process is blocked.
You need to add SIM.Trace () calls to clearly document the state changes during the life cycle of the message and disk I/O applications.
Modify JavaSOS as appropriate to solve problem 5.21 in the textbook (page 173). The problem states: Add a new system call DestroyMessageQueueSystemCall. This will allow the message queue to be used over again. Specify the call and implement it. Make sure it returns any message buffers in the queue to the free buffer pool. Keep track of the message queues that are still active, and change CreateMessageQueueSystemCall so that it will reuse message queues that have been destroyed. Then change ExitProcessSystemCall so that, when a process exits, any message queues it has created will be destroyed automatically.
You need to add SIM.Trace() calls to clearly document the execution of DestroyMessageQueueSystemCall as well as the automatic reclaiming of any message queue buffers in ExitProcessSystemCall. You also need to modify the message application in AppTests.java to demonstrate DestroyMessageQueueSystemCall.
One of the three application has been modified and the potential for a race condition has been introduced. You must first figure which of the three applications has the race condition and clearly document the reason why. Include the exact nature of the race condition and then implement a mechanism for eliminating the race condition.