Question

a) (25 pts) In round-robin scheduling, explain what size time quantum should be given to CPU bound and I/O bound processes.

b) (25 pts) When using the Banker’s algorithm for resource allocation, if the system is in an unsafe state, will that always lead to deadlock? Explain your answer!

c) (25 pts) Name and explain at least one difference between a mutex and binary semaphore.

d) (25 pts) What is a race condition? Provide sample pseudo-code to illustrate your answer

Answer 1

A-

• Round robin scheduling is similar to FCFS scheduling, except that CPU bursts are assigned with limits called time quantum.
• When a process is given the CPU, a timer is set for whatever value has been set for a time quantum.
  • If the process finishes its burst before the time quantum timer expires, then it is swapped out of the CPU just like the normal FCFS algorithm.
  • If the timer goes off first, then the process is swapped out of the CPU and moved to the back end of the ready queue.
• The ready queue is maintained as a circular queue, so when all processes have had a turn, then the scheduler gives the first process another turn, and so on.
• RR scheduling can give the effect of all processors sharing the CPU equally, although the average wait time can be longer than with other scheduling algorithms. In the following example the average wait time is 5.66 ms.

PROCESS	BURST TIME
P1	24
P2	3
P3	3

P1

P2

P3

P1

P1

P1

P1

P1

0 4 7 10 14 18 22 26 30

• The performance of RR is sensitive to the time quantum selected. If the quantum is large enough, then RR reduces to the FCFS algorithm; If it is very small, then each process gets 1/n^th of the processor time and share the CPU equally.
• BUT, a real system invokes overhead for every context switch, and the smaller the time quantum the more context switches are there. Most modern systems use time quantum between 10 and 100 milliseconds, and context switch times on the order of 10 microseconds, so the overhead is small relative to the time quantum.
• Turn around time also varies with quantum time, in a non-apparent manner.

In general, turnaround time is minimized if most processes finish their next cpu burst within one time quantum. However, if it is made too large, then RR just degenerates to FCFS. A rule of thumb is that 80% of CPU bursts should be smaller than the time quantum.

B-

In Bankers algorithm the unsafe state will not always lead to deadlock. The explanation is as follows:

Deadlock means something specific: there are two (or more) processes that are currently blocked waiting for each other.

In an unsafe state you can also be in a situation where there might be a deadlock sometime in the future, but it hasn't happened yet because one or both of the processes haven't actually started waiting.

Process A                  Process B
lock X                     lock Y           # state is "unsafe"
                           unlock Y
lock Y                                      # state is back to "safe" (no deadlock this time.  We got lucky.)

Consider a system with 12 tape drives with:
Process       Max Need       Current
P0:             10              5
P2:              9              3

This is an unsafe state. But we're not in a deadlock. There's only 4 free drives, so, for example, if P0 does request an additional 5, and P2 does request an additional 1, we will deadlock, but it hasn't happened yet. And P0 might not request any more drives, but might instead free up the drives it already has. The Max need is over all possible executions of the program, and this might not be one of the executions where we need all 10 drives in P0.

C-

As per operating system terminology, mutex and semaphore are kernel resources that provide synchronization services (also called as synchronization primitives). Why do we need such synchronization primitives? Won’t be only one sufficient? To answer these questions, we need to understand few keywords. Please read the posts on atomicity and critical section. We will illustrate with examples to understand these concepts well, rather than following usual OS textual description.

The producer-consumer problem:

Note that the content is generalized explanation. Practical details vary with implementation.

Consider the standard producer-consumer problem. Assume, we have a buffer of 4096 byte length. A producer thread collects the data and writes it to the buffer. A consumer thread processes the collected data from the buffer. Objective is, both the threads should not run at the same time.

Using Mutex:

A mutex provides mutual exclusion, either producer or consumer can have the key (mutex) and proceed with their work. As long as the buffer is filled by producer, the consumer needs to wait, and vice versa.

At any point of time, only one thread can work with the entire buffer. The concept can be generalized using semaphore.

Using Semaphore:

A semaphore is a generalized mutex. In lieu of single buffer, we can split the 4 KB buffer into four 1 KB buffers (identical resources). A semaphore can be associated with these four buffers. The consumer and producer can work on different buffers at the same time.

Misconception:

There is an ambiguity between binary semaphore and mutex. We might have come across that a mutex is binary semaphore. But they are not! The purpose of mutex and semaphore are different. May be, due to similarity in their implementation a mutex would be referred as binary semaphore.

Strictly speaking, a mutex is locking mechanism used to synchronize access to a resource. Only one task (can be a thread or process based on OS abstraction) can acquire the mutex. It means there is ownership associated with mutex, and only the owner can release the lock (mutex).

Semaphore is signaling mechanism (“I am done, you can carry on” kind of signal). For example, if you are listening songs (assume it as one task) on your mobile and at the same time your friend calls you, an interrupt is triggered upon which an interrupt service routine (ISR) signals the call processing task to wakeup.

D-

Race Condition-

  

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.

A simple example of a race condition is a light switch. In some homes there are multiple light switches connected to a common ceiling light. When these types of circuits are used, the switch position becomes irrelevant. If the light is on, moving either switch from its current position turns the light off. Similarly, if the light is off, then moving either switch from its current position turns the light on. With that in mind, imagine what might happen if two people tried to turn on the light using two different switches at exactly the same time. One instruction might cancel the other or the two actions might trip the circuit breaker.

Race conditions are most commonly associated with computer science. In computer memory or storage, a race condition may occur if commandsto read and write a large amount of data are received at almost the same instant, and the machine attempts to overwrite some or all of the old data while that old data is still being read. The result may be one or more of the following: a computer crash, an "illegal operation," notification and shutdown of the program, errors reading the old data or errors writing the new data. A race condition can also occur if instructions are processed in the incorrect order.

Writer Thread

r = 0; w = 1; l = 2; //assign start slot numbers
while(1) { 
  write_slot(w);
  l = w; //last written slot is w 
  w = not(r,l) //assigns next slot so that w is neither r or l
}

Reader Thread

while(1) {
 r = l; //read from latest write
 read(r);
}