;New state variables{{c|KThread}} has a new state variable {{c|joinedOnMe}}, a {{c|ThreadQueue}}. , and {{c|isJoined}}, a {{c|boolean}} ;Implementation details

* Have a thread attempt to {{c|join()}} to itself, call {{c|join()}} on the same (but different) a second thread multiple times, and attempt to call {{c|join()}} on a third finished thread (all separately). These should all return immediately as this is the expected behavior.

Re-enable interrupts;

==ConditionCondition2.java==

;New state variablesCondition2 has a new state variable {{c|waitQueue}}, a {{c|ThreadQueue}} with {{c|transferPriority}} flag set to false.  ;Implementation details* In the {{c|sleep()}} method, we disable interrupts, the current thread is added to the {{c|waitQueue}} of threads, the corresponding lock is released, and the current thread is put to sleep. When it wakes up, the thread attempts to reacquire the condition corresponding lock and interrupts are re-enabled.

* The {{c|wakeAll()}} method also disables the interrupts and stored stores the next thread from {{c|waitQueue}} as a {{c|KThread}} variable , {{c|nextThread}}. While {{c|nextThread}} is not null, the method will ready that thread and reset set {{c|nextThread}} as to the next thread from {{c|waitQueue}}. This procedure continues until there are no more threads in {{c|waitQueue}}.

* {{c|Condition2.java}} was tested using a class called {{c|CondThread}}, which implements {{c|Runnable}}. The class is instantiated with an integer {{c|iterations}}, a lock, a {{c|Condition2}} variable to call {{c|sleep()}} on, and a {{c|Condition2}} variable to call {{c|wake()}} on. When a {{c|CondThread}} runs, it acquires the lock, then enters a for-loop of 6 iterations. On each iteration, the thread will print out a debug statement noting that the current thread is on the ith iteration. When the loop iteration number is equal to {{c|iterations}}, threads can take one of three actions:*#If the thread's ID is '0', then that thread is the waking thread and calls {{c|wake()}} on its second condition variable.*#If the thread's ID is '0-all', it calls {{c|wakeAll()}} on its second condition variable*#Otherwise, it goes to sleep on its first condition variable. Using the output, we verify that the threads all run in the correct order and all execute to completion.* Sleep several threads on the condition variable. Upon waking, these threads should print a unique statement and perform a {{c|wake() }} on the condition variable. Have one thread perform an initial {{c|wake() }} on the condition variable and verify that all threads are executed.* Sleep several threads on several various condition variables. Verify via console print statements that the proper threads wake up at the correct times according to which condition variable they were sleeping on.* Sleep several threads on the condition variable, then have one final thread wake them all with {{c|wakeAll()}}. Verify that all threads have woken up via console print statements.* Sleep several threads on several various condition variables, then have one thread call {{c|wakeAll()}} on one of the condition variables. Verify via console print statements that all the threads put to sleep on that condition variable wake up and that only those threads wake up.

Sleep{{c|<pre>sleep(){ Disable Interrupts; Add current thread to wait queue; Release the lock; Put the current thread to sleep; Acquire the lock; Re-enable Interrupts;}</pre>}}

Wake{{c|<pre>wakeAll(){AssertTrue (lock held by current thread); Disable interrupts;If While there is a thread are threads on the wait queue, remove : Remove the first thread and wake it; Re-enable interrupts; }</pre>}}

WakeAll=={{c|waitUntil(){}}=====Implementation===Disable interrupts;New state variablesWhile there are Alarm has a new instance variable, {{c|waitingThreads}}, which is a Java {{c|PriorityQueue}} of waiting threads on with the wait queuetarget wake time as their priority. It also contains a new inner class named {{c|WaitingThread}}, call wake()which contains a reference to a {{c|KThread}} and its associated {{c|wakeTime}}.;Re-enable interrupts; The {{c|PriorityQueue waitingThreads}}will be populated with instances of this inner class.

 ==WaitUntil()=====;Implementation===Alarm has a new instance variable, waitingThreads, which is a Java PriorityQueue of waiting threads with the target wake time as their priority. It also contains a new inner class named waitingThread, which contains a reference to the KThread and its associated wakeTime.details* {{c|waitUntil() }} creates a new instance of {{c|waitingThread}}, which will associate the currentThread current thread with the give given time argument. It will then add this {{c|waitingThread }} instance to the {{c|PriorityQueue }} and put the current thread to sleep. This method is atomic. * {{c|timerInterrupt() peek }} peeks at the first {{c|WaitingThread }} in the {{c|waitQueue }} and check checks if its associated wake time is less than or equal to the current time. If it is, this method will pop the {{c|WaitingThread }} off the {{c|waitQueue }} and wake the associated thread. This process is repeated until the wake time of the first {{c|WaitingThread }} is greater than the current time.

* Have the timer interrupt print a debug statement, and have timed threads print the times they go to sleep and when they have woken up. Verify that they wake up relatively close to their expected exit wake time. * Make sure threads called with illegal times return immediately. Test threads that go to sleep chronologically in order (1, 500, 1050) as well as threads that go to sleep with the same times ( 50, 50) and threads that go to sleep in reverse order (500, 250). Verify they all wake up when they are supposed to.

{{c|<pre>waitUntil(time){

} </pre>}}

{{c|<pre>timerInterrupt(){

}</pre>}}

We add new ;New state variables (a lock, four counters, and two condition variables): {{c|<pre>Lock lock = new Lock()int activeSpeakers= 0int waitingSpeakers= 0int activeListeners= 0int waitingListeners= 0Condition speakers

Condition return</pre>}} ;Implementation details* The first lone speaker or listener will be counted as ''active'', or in the process of exchanging a message and returning, and will sleep on the {{c|return }} condition variable until its counterpart wakes it up so that they can both return. * A second thread performing the same action as a currently active thread will be counted as ''waiting'', and be put to sleep on its respective condition variable. Otherwise, it will check if there is an ''active '' thread of its counterpart action waiting on the {{c|return }} condition variable. If there isn’tisn't, it will attempt to wake waiting threads of its counterpart action prior to going to sleep on the return condition variable. If there is a counterpart ''active '' thread, it will wake it up and they both will return. Prior to returning, a the counterpart action will also attempt to wake sleeping ''waiting '' threads of its type.* Any interjecting threads that execute in between an exchange of message will be stopped by the ''active '' counters, which do not decrement until BOTH '''both''' counterparts in the exchange have returned.

First, we set up a manual sequence of {{c|speak() }} and {{c|listen() }} actions on different threads and executed them in a particular order, verifying that the resulting sequence of messages was correct, monitored via print statements to the console

ThirdFinally, we used testing functions: MassSpeaker and MassListener are designed to be run by a single thread each. These runnables iterate until a given limitrepeated the same procedure, and on each iteration, there is a 50% chance that a speak (or listen) is called. After each iteration, the thread yields to the opposite thread to do but intermingled the same. Debug statements will display what threads are doing at each iteration and how messages are being exchanged. With this we can generate large amounts creation of calls with randomized orders between two threads, speakers and will be able to verify all speaks are correctly received by a listenlisteners via {{c|.A second set of runnables, MassTSpeaker and MassTListener, are designed to fork off several threads themselves()}}, with each of these forked threads performing a single speak or listen. These forked threads are also executed with 50% chance on each iteration to provide random ordering. We can also verify if such that listeners would start listening before all threads are correctly paired off via print statements to consolethe speakers were queued up.

The latter two To be able to perform these tests were run with up to 500 threads , we created a number of speakers helper classes which implement Runnable. {{c|MassSpeaker}} and listeners {{c|MassListener}} are designed to be run by a single thread each (with . These will iterate until a temporary override given limit, and on each iteration, there is a 50% chance that a speak (or listen) is called. After each iteration, the thread yields to the opposite thread to do the number same. Debug statements will display what threads are doing at each iteration and how messages are being exchanged. With this we can generate large amounts of max calls with randomized orders between two threads in Nachos) , and the number will be able to verify all speaks are correctly received by a listen. A second set of listen runnables, {{c|MassTSpeaker}} and {{c|MassTListener}}, are designed to fork off several threads themselves, with each of these forked threads performing a single speak operations was analyzed or listen. These forked threads are also executed with 50% chance on each iteration to provide random ordering. We can also verify if all threads are correctly paired off via script. The speakers and listeners would print statements while executing code, which allowed us to perform this analysisconsole.

===Pseudocode==={|| style="vertical-align: top;"| speak(int word) {

Sleep as an active speakerwaiting to return;

Sleep as an active listenerwaiting to return;

;New state variables are shown * {{c|PriorityQueue.holder}} - this ThreadState corresponds to the holder of the resource signified by the class they appear in: * {{c|PriorityQueue: KThread lastThreadThreadState: int donatedPriorityPriorityScheduler: TreeSet¬Ђlong (time), KThread¬ї .waitQueue}} - an ArrayList of ThreadStates waiting on this resource. Unsorted.* nextThread()* This method retrieves and removes the highest priority thread off the Priority{{c|PriorityQueue.dirty}} -Time set. It calculates this to true when a new thread's priority based on priorities is added to the queue, or any of the threads waiting queues in the queuewaitQueue flag themselves as dirty.* {{c|PriorityQueue. It resets effective}} - the priority cached highest of thread previously the effective priorities in the lastThread position to its original prioritywaitQueue. The thread to be returned This value is invalidated while dirty is also set as the new lastThreadtrue. * pickNextThread()* This method retrieves the first thread from the Priority{{c|ThreadState.myResources}} -Time set without removing it from collection of PriorityQueues that signify the set. It creates a new ThreadState from Locks or other resources that this thread and returns the ThreadStatecurrently holds. * getEffectivePriority()* This method sums the associated thread's priority and its donatedPriority{{c|ThreadState. If waitingOn}} - collection of PriorityQueues corresponding to resources that this sum is less than 7, the method returns the sum. Otherwise, the max priority 7 is returnedthread has attempted to acquire but could not.* setPriority() This method will change the actual priority of the thread associated with the {{c|ThreadState. The effective}} - the cached effective priority of lastThread must also be by difference between current threads priority and new prioritythis thread. this value is invalidated when dirty is true* waitForAccess(priorityQueue) This method puts thread associated with the threadState onto the Priority{{c|ThreadState.dirty}} -Time set. The set sorts all threads by to true when this thread's priorityis changed, then timeor when one of the queues in myResources flags itself as dirty.  ;Implementation overviewThe associated thread will then be put to sleep. This method will also recalculate effective priority: it will add up all priorities idea here is that {{c|Thread}}s keep track of the threads in {{c|PriorityQueue}}s corresponding to both the set resources that they are currently holding and donate it those that they want to the lastThreadhold.* acquireWe can do this via hooks in {{c|PriorityQueue}}'s {{c|waitForAccess()}}, {{c|acquire}}, and {{c|nextThread}} methods.* This method calculates the priority of the associated Once we have this, every time a thread based tries to wait on priorities a queue, or takes control of a queue, we can tell the threads waiting queue that its overall effective priority may have changed, and it can, in turn, tell the queue. It resets thread that currently holds the priority resource that one of the thread previously {{c|PriorityQueue}}s it holds may have had its priority changed. That holder can in turn tell the lastThread position same to its original prioritythe {{c|PriorityQueue}}s that it is waiting on, and so forth. The associated Eventually a thread , which is set as the new lastThreadholding a resource that everyone needs, but has a low priority, will be marked for priority recalculation and thus priority escalation.

Algorithm for solving boat problem (high level):If there are no children on Molokai or if there are no adults left on Oahu, two children from Oahu will pilot over and one will return to Molokai. If there is a child on Molokai, an adult will pilot over to Molokai and the child will bring the boat back to Oahu. This process, carried to completion eventually results in all of the adults and children on Molokai. ;Shared New state variables(all shared)

;Basic ideaImplementation overviewIf there are no children on Molokai or if there are no adults left on Oahu, two children from Oahu will pilot over and one will return to Molokai. If there is a child on Molokai, an adult will pilot over to Molokai and the child will bring the boat back to Oahu. This process, carried to completion eventually results in all of the adults and children on Molokai. Each thread will attempt to acquire the lock (which essentially represents control over the boat). If the thread can perform one of the tasks fitting for the current state of the world, it executes it. Otherwise, it will go to sleep on the condition variable corresponding to its current role and location.

;Algorithm Implementation details