Nachos Phase 1 Code -Hints and Comments

Task I –Implement join() Join method: Should have a test to prevent a thread from trying to join itself. Interrupts should be disabled – they must be disabled before calling sleep(). The calling thread is the current thread and it must be stored so that it can be awoken later. I think it’s a good idea to store the threads in a list so that more than one thread can join a given thread. The documentation seems to suggest that a thread can only be joined once, so I didn’t take marks off for not handling multiple threads, although this seems an unnecessary limitation. You may find having multiple threads join a thread useful in testing.

Task I (continued) Don’t forget to wake the sleeping thread(s). This should happen in the finish method. The sleeping threads should be moved back to the ready queue by calling the ready() method. Some groups put the code to wake the thread in the restoreState method just before the thread was destroyed. This should work as well, since the finished thread should be destroyed by the next thread. In general though, the time a thread finishes and the time it is destroyed may not be the same, so I think it is better to put the code in the finish method.

Task II Implement Condition2 This task was generally well done. Make sure to check that the current thread has the lock for all methods. The sleep method stores the threads waiting on this condition in a queue. After waking the thread must re-acquire the lock. Interrupts should be disabled to make the operation atomic. The wake methods removes the first element in the queue (unless the queue is empty) and puts it back on the ready queue. Again, interrupts should be disabled to make the operation atomic. The wakeAll method is similar, but instead of waking just one thread it wakes all the threads in the queue.

Task III Implement waitUntil method The waitUntil(long x) method must first determine the wake time of the thread by adding x to the current time. The waiting threads must be stored in a queue. The most efficient method is to use a priority queue so the whole queue doesn’t have to be searched. Remember, the timerInterrupt method is called every 500 ticks, so it should be efficient. The problem is that we have to store both the thread and the wake time. One way to do this is to create a new class, consisting of the thread and the wake time, that implements the Comparable interface. Then implement the compareTo method to allow objects of this type to be sorted by the wake time. (You should have learned how to do this in the Data Structures course).

Task III (continued) Java now has a priority queue (as of version 1.5) but nachos doesn’t use java 1.5 so you won’t be able to use it. The priority queue can also be easily implemented with a linked list – just insert the objects in ascending order. Other groups used heaps or Treesets to implement the priority queue. These methods should work as well. If a priority queue is used, the timerInterrupt can use a while loop to wake the threads whose wake time is less than the current time.

Task IV Implement Communicator This is the most difficult of the tasks. One key to getting this class to work is to understand how different variable types work in threads. In a context switch the variables on the stack are saved for each thread. These include the parameters and local variables. This means that parameters and local variables are unique for each thread. In contrast, data on the heap is global to all threads. This includes any instance variables. Since in this class we must pass data from the speaker to the listener we need to use an instance variable to do this.

Task IV (Continued) The speak(int word) method: One detail to determine, is whether the speaker should transfer the message (i.e. move the word from the parameter to the instance variable) before or after going to sleep on the condition. If we move the message before going to sleep we have the problem of it being overwritten by another speaker before it is picked up by a listener. Remember that the sleep method in the condition class releases the lock. This means a number of speakers can be waiting on the condition at the same time, so we must ensure that their messages don’t get lost. The way our group got around this was to store the messages in a queue. However, Doctor Passi doesn’t like this method, so I will suggest another method.

Task IV (Continued) If the speaker can’t store the message before going to sleep, it must do it after waking. This requires a compound condition; the speaker must sleep while either there are no listeners or the message from the previous speaker has not yet been picked up by a listener (this will require a boolean instance variable). Once the speaker exits the while loop it can leave its message and set the boolean variable to indicate that there is a message to pick up because it knows there is at least one listener waiting. It then wakes a listener and exits.

Task IV (Continued) The int listen() method: After entering the critical region, the listener increments the counter keeping track of the number of listeners waiting. It then wakes a speaker (if there is one). This ensures that if a speaker was only waiting for a listener (no message waiting from the last speaker) it will be woken. The listener must sleep while there is no message to pick up (the boolean variable). On exiting the while loop it decrements the number of listeners waiting and can pick up the message. The message should be moved to a local variable. This is because the listener must release the lock before returning. This means the instance variable containing the message might be overwritten before the listener returns the message. After moving the message to a local variable, the listener sets the boolean variable to indicate the message has been picked up (no message waiting). Then wake up a speaker (if there is one), since there may be a speaker waiting only for the boolean flag (there are other listeners). The listener can then release the lock and return the local variable.

Task IV (Continued) You should just use one lock, but it’s probably simpler to use 2 condition variables, one for the speakers and one for the listeners, if you use this method.

Task V Implement ReactWater This task was well done by all groups, so I have no additional comments to make.

Additional Comments Test Cases Its important to think about how to test your code. The test cases should include both what you want to test and an outline of how you are going to test it. You should test both normal conditions and any special cases.

Compiling The Code The group0X/nachos (X is your group number) directory contains the file Makefile. This file contains the names of the source files to be compiled listed by directory. To get it to compile ReactWater type ReactWater in the threads section. E.g. threads = ThreadedKernel KThread Alarm \ Scheduler ThreadQueue RoundRobinScheduler \ Semaphore Lock Condition SynchList \ Condition2 Communicator Rider ElevatorController \ PriorityScheduler LotteryScheduler Boat ReactWater Add any other new classes in here as well. To compile, go to directory group0X/nachos/proj1 and type gmake. To run nachos key in nachos in the same directory (group0X/nachos/proj1).

Where to put Your Test Code When nachos starts up it calls ThreadedKernel (in the threads directory). ThreadedKernel has a method called selfTest. You can add your testing code here. Probably the cleanest way to do this is to have selfTest methods in each of the classes and call these methods. –i.e. in ThreadedKernel’s selfTest add: Condition2.selfTest(); ReactWater.selfTest(); etc. Add the test code to the selfTest method in each class.

Testing When the main thread ends, nachos will shut down. This isn’t supposed to happen. According to the documentation it should wait for all threads to finish. This easiest way to get around this problem is to have the main thread join each test thread, so the main thread doesn’t end until all test threads have finished. This won’t work if your join is limited to one thread, which is one reason I recommend keeping a queue of joined threads in task I.