1. Tutorial 3: Homework 2 and Project 2

2. Project 1: Review
The class as a whole did well! There is a correlation between lab attendance and project marks. Attendance is not compulsory but is recommended. Remember to utilise of the ECS forums.

3. Project 1: Commenting Code
Code comments should:
Justify design decisions.
Make vague code understandable.
Be concise.
Is it necessary to comment the declaration of a loop counter?

4. Project 1: Code Presentation
Why is this important?
Improves readability.
Improves ‘markability’.
Remove commented-out code prior to submission.
Be proud of your work!

5. Homework 2
Q1: 2.22: Does Peterson’s solution to the mutual-exclusion problem shown in Fig (page 125) work when process scheduling is preemptive? How about when it is nonpreemptive?

6. Homework 2
A: It certainly works with preemptive scheduling. In fact, it was designed for that case. When scheduling is nonpreemtive, it might fail. Consider the case in which turn is initially 0 but process 1 runs first. It will just loop forever and never release the CPU.
Preempting the other process allows the two threads to run concurrently. Without preemtion one process can go into the waiting state (busy wait) and the other process will never be able to use the CPU to take its turn.

7. Homework 2 Q2: 2.26: What is a race condition?
A: A race condition is an undesirable situation that occurs when a device or system attempts to perform two or more operations at the same time, but because of the nature of the device or system, the operations must be done in the proper sequence to be done correctly.

8. Homework 2
Q3: 2.28: The producer consumer problem can be extended to a system with multiple producers and consumers that write (or read) to (from) one shared buffer. Assume that each producer and consumer runs in its own thread. Will the solution presented in Fig (page 131) using semaphores, work for this system?

9. Homework 2
A: Yes, it will work as is. At a given time instance, only one producer (or consumer) can add (or remove) and item to/from the buffer.

10. Homework 2
Q4: 6.9: Suppose that there is a resource deadlock in a system. Give an example to show that the set of processes deadlocked can include processes that are not in the circular chain in the corresponding resource allocation graph.
A: P1 is not in the cycle but is deadlocked. P1 R2 R3 P2 P3 R1

11. Homework 2
Q5: 6.28: One way to eliminate circular wait is to have a rule saying that a process is entitled only to a single resource at any moment. Given an example to show that this restriction is unacceptable in many cases.
A: Consider a process that needs to cope a huge file from a tape drive to a printer. The entire file cannot be read at one time due to limited memory. Therefore it has to: Acquire tape, copy next portion, release tape, acquire printer, print file, release printer, etc. This will lengthen execution time. As the printer is also released, there is no guarantee it will all be printed on continuous pages.

12. Homework 2
Q6: 6.35: Explain the difference between deadlock, livelock, and starvation. A:
Deadlock occurs when a set of processes are blocked waiting for an event that only some other process (also blocked) can cause.
Processes in a livelock are not blocked. Instead, they continue to execute checking for a condition to become true that will never become true. In addition to the resource they are holding, processes in livelock continue to consume CPU time.
Starvation occurs when a stream of new processes have higher priority than the process being starved (it never gets to run). Unlike deadlock or livelock, starvation can terminate on its own, e.g. when existing processes with higher priority terminate and no new processes with higher priority arrive.

13. Project 2: Overview
Pintos currently uses FCFS ordering on queues with periodic interrupt to implement RR-like behaviour. Project aim: Implement a priority-based scheduling mechanism. A new version of Pintos is needed: pintos2.tar.gz. Priorities are defined in macros in thread.h. -> Lowest priority = 0, Highest priority = 63.

14. Project 2: Part 1 Implement priority scheduling for threads.
Pre-emption is an important component of this part.
A lower priority thread must yield to a higher priority thread.
Consider the situations where this may occur.
Pass the following tests:
alarm­-priority
priority­-fifo
priority­-preempt
priority-­change

15. Project 2: Part 2
Implement priority scheduling for semaphores, locks and condition variables.
The thread waiting for a semaphore (for example) with the highest priority should be woken first. The same goes for locks and condition variables.
Pass the following tests:
priority-sema
priority-condvar
Why is there no test for locks? Hint: look at how locks are implemented.

16. Project 2: Part 3 Implement priority donation.
This is used to allow a high priority thread to donate its priority to a low priority thread if it has to wait on it. Say thread A is waiting on a lock held by thread B, A should give its priority to B until the lock is released. Following the release, it should recall the donation.
Pass the following tests:
priority-donate-one
priority-donate-lower
priority-donate-sema
priority-donate-multiple
priority-donate-multiple2

17. Project 2: Reminders Indicate where your contributions start and end.
e.g. /* MY CODE BEGINS */ …
/* MY CODE ENDS */
Only submit code that you have edited.
-> Do not zip the Pintos codebase and submit that.