COT 5611 Operating SystemsDesign Principles Spring 2012

Dan C. Marinescu

Office: HEC 304

Office hours: M-Wd 5:00-6:00 PM

Lecture 20

Lecture 20 – Monday March 26, 2012

Reading assignment: Chapter 9 from the on-line text

Last time – Thread management Address spaces and multi-level memories Kernel structures for the management of multiple cores/processors and

threads/processes Locks and before-or-after actions; hardware support for locks YIELD

3/21/2012 2

Lecture 20

Today Conditions for thread coordination – Safety, Liveness, Bounded-Wait, Fairness Critical sections – a solution to critical section problem Deadlocks Signals Semaphores Monitors Thread coordination with a bounded buffer.

WAIT NOTIFY AWAIT ADVANCE SEQUENCE TICKET

3/21/2012 3

Lecture 19

Thread coordination

Critical section code that accesses a shared resource Race conditions two or more threads access shared data and the result

depends on the order in which the threads access the shared data. Mutual exclusion only one thread should execute a critical section at any

one time. Scheduling algorithms decide which thread to choose when multiple

threads are in a RUNNABLE state FIFO – first in first out LIFO – last in first out Priority scheduling EDF – earliest deadline first

Preemption ability to stop a running activity and start another one with a higher priority.

Side effects of thread coordination Deadlock Priority inversion a lower priority activity is allowed to run before one with a higher priority

3/21/2012 4

Lecture 20

Solutions to thread coordination problems must satisfy a set of conditions

1. Safety: The required condition will never be violated. 2. Liveness: The system should eventually progress irrespective of contention.3. Freedom From Starvation: No process should be denied progress for ever. That

is, every process should make progress in a finite time. 4. Bounded Wait: Every process is assured of not more than a fixed number of

overtakes by other processes in the system before it makes progress. 5. Fairness: dependent on the scheduling algorithm • FIFO: No process will ever overtake another process. • LRU: The process which received the service least recently gets the service next.

For example for the mutual exclusion problem the solution should guarantee that:Safety the mutual exclusion property is never violatedLiveness a thread will access the shared resource in a finite time Freedom for starvation a thread will access the shared resource in a finite timeBounded wait a thread will access the shared resource at least after a given number of

accesses by other threads.

3/21/2012 5

Lecture 20

A solution to critical section problem

Applies only to two threads Ti and Tj with i,j ={0,1} which share integer turn if turn=i then it is the turn of Ti to enter the critical section

boolean flag[2] if flag[i]= TRUE then Ti is ready to enter the critical section

To enter the critical section thread Ti

sets flag[i]= TRUE

sets turn=j

If both threads want to enter then turn will end up with a value of either i or j and the corresponding thread will enter the critical section.

Ti enters the critical section only if either flag[j]= FALSE or turn=i The solution is correct

Mutual exclusion is guaranteed The liveliness is ensured The bounded-waiting is met

But this solution may not work as load and store instructions can be interrupted on modern computer architectures

3/21/2012 6

Lecture 20 73/21/2012

Lecture 20

Deadlocks

Happen quite often in real life and the proposed solutions are not always logical: “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone.” a pearl from Kansas legislation.

Deadlock jury. Deadlock legislative body.

3/21/2012 8

Lecture 20

Examples of deadlock

Traffic only in one direction.

Solution one car backs up (preempt resources and rollback). Several cars may have to be backed up .

Starvation is possible.

3/21/2012 9

Lecture 20

A B

J

K

J

K

A B

3/21/2012 10

Lecture 20

Thread deadlock

Deadlocks prevent sets of concurrent threads/processes from completing their tasks.

How does a deadlock occur a set of blocked threads each holding a resource and waiting to acquire a resource held by another thread in the set.

Example locks A and B, initialized to 1

P0 P1

wait (A); wait(B)

wait (B); wait(A)

Aim prevent or avoid deadlocks

3/21/2012 11

Lecture 20

System model

Resource types R1, R2, . . ., Rm (CPU cycles, memory space, I/O devices)

Each resource type Ri has Wi instances. Resource access model:

request use release

3/21/2012 12

Lecture 20

Simultaneous conditions for deadlock

Mutual exclusion: only one process at a time can use a resource. Hold and wait: a process holding at least one resource is waiting to

acquire additional resources held by other processes. No preemption: a resource can be released only voluntarily by the

process holding it (presumably after that process has finished). Circular wait: there exists a set {P0, P1, …, P0} of waiting processes such

that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and P0 is waiting for a resource that is held by P0.

3/21/2012 13

Lecture 20

Wait for graphs

 Processes are represented as nodes, and an edge from thread Ti  to thread Tj  implies that Tj  is holding a resource that  Ti  needs and thus  is waiting for Tj  to release its lock on that resource. A deadlock exists if the graph

contains any cycles.

143/21/2012

Lecture 20

Semaphore Abstract data structure introduced by Dijkstra to

reduce complexity of threads coordination; has two components C count giving the status of the contention for

the resource guarded by s L list of threads waiting for the semaphore s

Two operations P - wait(): Decrements the value of a semaphore

variable by 1. If the value becomes negative, the process executing wait() is blocked, i.e., added to the semaphore's queue.

V- signal(): Increments the value of semaphore variable by 1. After the increment, if the value is negative, it transfers a blocked process from the semaphore's queue to the ready queue.

3/21/2012 15

Lecture 20

Counting and binary semaphores

Counting semaphore – used for pools of resources (multiple units), e.g., cores.

 If a process performs a P operation on a semaphore that has the value zero, the process is added to the semaphore's queue. When another process increments the semaphore by performing a V operation, and there are processes on the queue, one of them is removed from the queue and resumes execution. When processes have different priorities the queue may be ordered by priority, so that the highest priority process is taken from the queue first.

Binary semaphore: C is either 0 or 1.

163/21/2012

Lecture 20

The wait and signal operations

P (s) (wait)

{

If s.C > 0 then s.C − −;

else join s.L;

}

V (s) (signal)

{

If s.L is empty then s.C + +;

else release a process from s.L;

}

3/21/2012 17

Lecture 20

Monitors

Semaphores can be used incorrectly multiple threads may be allowed to enter the critical section guarded by the semaphore may cause deadlocks

Threads may access the shared data directly without checking the semaphore. Solution encapsulate shared data with access methods to operate on them. Monitors an abstract data type that allows access to shared data with specific

methods that guarantee mutual exclusion

3/21/2012 18

Lecture 203/21/2012 19

Lecture 20

Asynchronous events and signals

Signals, or software interrupts, were originally introduced in Unix to notify a process about the occurrence of a particular event in the system.

Signals are analogous to hardware I/O interrupts: When a signal arrives, control will abruptly switch to the signal handler. When the handler is finished and returns, control goes back to where it came from

After receiving a signal, the receiver reacts to it in a well-defined manner. That is, a process can tell the system (OS) what they want to do when signal arrives: Ignore it. Catch it and deliver it. In this case, it must specify (register) the signal handling

procedure. This procedure resides in the user space. The kernel will make a call to this procedure during the signal handling and control returns to kernel after it is done.

Kill the process (default for most signals).

Examples: Event - child exit, signal - to parent. Control signal from keyboard.

3/21/2012 20

Lecture 20

Signals state and implementation

A signal has the following states: Signal send - A process can send signal to one of its group member process

(parent, sibling, children, and further descendants). Signal delivered - Signal bit is set. Pending signal - delivered but not yet received (action has not been taken). Signal lost - either ignored or overwritten.

Implementation: Each process has a kernel space (created by default) called signal descriptor having bits for each signal. Setting a bit is delivering the signal, and resetting the bit is to indicate that the signal is received. A signal could be blocked/ignored. This requires an additional bit for each signal. Most signals are system controlled signals.

3/21/2012 21

Lecture 20

Back to thread coordination with a bounded buffer

The bounded buffer is a shared resource thus it must be protected; the critical section is implemented with a lock.

The lock must be released if the thread cannot continue. Spin lock a lock which involves busy wait. The thread must relinquish control of the processor, it must YIELD.

3/21/2012 22

Lecture 203/21/2012 23

Lecture 20

1 2 N-1N-2

out

inRead from the bufferlocation pointed by out

Write to the bufferlocation pointed by out

shared structure buffer message instance message[N] integer in initially 0 integer out initially 0 lock instance buffer_lock initially UNLOCKED

procedure SEND (buffer reference p, message instance msg) ACQUIRE (p_buffer_lock) while p.in – p.out = N do /* if buffer full wait RELEASE (p_buffer_lock) YIELD() ACQUIRE (p_buffer_lock) p.message [p.in modulo N] ß msg /* insert message into buffer cell p.in ß p.in + 1 /* increment pointer to next free cell RELEASE (p_buffer_lock)

procedure RECEIVE (buffer reference p) ACQUIRE (p_buffer_lock) while p.in = p.out do /* if buffer empty wait for message RELEASE (p_buffer_lock) YIELD() ACQUIRE (p_buffer_lock) msgß p.message [p.in modulo N] /* copy message from buffer cell p.out ß p.out + 1 /* increment pointer to next message return msg

0 1

3/21/2012 24

Lecture 20

Coordination with events and signals

We introduce two events p_room event which signals that there is room in the buffer p_notempty event which signals that there is a new item in the buffer

We also introduce two new system calls WAIT(ev) wait until the event ev occurs NOTIFY(ev) notify the other process that event ev has occurred.

SEND will wait if the buffer is full until it is notified that the RECIVE has created more room SEND WAIT(p_room) and RECIVE NOTIFY(p_room)

RECEIVE will wait if there is no new item in the buffer until it is notified by SEND that a new item has been written RECIVEWAIT(p_notempty) and SENDNOTIFY(p_notempty)

3/21/2012 25

Lecture 203/21/2012 26

Lecture 20

NOTIFY could be sent before the WAIT and this causes problems

The NOTIFY should always be sent after the WAIT. If the sender and the receiver run on two different processor there could be a race condition for the notempty event.

Tension between modularity and locks Several possible solutions: AWAIT/ADVANCE, semaphores, etc

3/21/2012 27

Lecture 20

AWAIT - ADVANCE solution A new state, WAITING and two before-or-after actions that take a RUNNING

thread into the WAITING state and back to RUNNABLE state. eventcount variables with an integer value shared between threads and the

thread manager; they are like events but have a value. A thread in the WAITING state waits for a particular value of the eventcount AWAIT(eventcount,value)

If eventcount >value the control is returned to the thread calling AWAIT and this thread will continue execution

If eventcount ≤value the state of the thread calling AWAIT is changed to WAITING and the thread is suspended.

ADVANCE(eventcount) increments the eventcount by one then searches the thread_table for threads waiting for this eventcount if it finds a thread and the eventcount exceeds the value the thread is waiting for then

the state of the thread is changed to RUNNABLE

3/21/2012 28

Lecture 203/21/2012 29

Lecture 20

Implementation of AWAIT and ADVANCE

3/21/2012 30

Lecture 203/21/2012 31

Lecture 20

Solution for a single sender and single receiver

3/21/2012 32

Lecture 20

Supporting multiple senders: the sequencer

Sequencer shared variable supporting thread sequence coordination -it allows threads to be ordered and is manipulated using two before-or-after actions.

TICKET(sequencer) returns a negative value which increases by one at each call. Two concurrent threads calling TICKET on the same sequencer will receive different values based upon the timing of the call, the one calling first will receive a smaller value.

READ(sequencer) returns the current value of the sequencer

3/21/2012 33

Lecture 20

Multiple sender solution; only the SEND must be modified

3/21/2012 34