CGS 3763 Operating Systems Concepts

Spring 2013

Dan C. Marinescu
Office: HEC 304
Office hours: M-Wd 11:30 - 12:30 AM

Lecture 9 Monday, January 28, 2013

Last time:
Today:

Thread coordination, Locks

Next time

1/21/16

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

Lecture 18

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 nite time.
4. Bounded Wait: Every process is assured of not more than a xed 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 violated
Liveness a thread will access the shared resource in a nite time
Freedom for starvation a thread will access the shared resource in a nite time
Bounded wait a thread will access the shared resource at least after a xed number of
accesses by other threads.

Lecture 18

Thread coordination problems

Dining philosophers
Critical section

Lecture 18

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

Lecture 18

Lecture 18

Locks; Before-or-After actions

Locks shared variables which acts as a flag to coordinate access to a

shared data. Manipulated with two primitives

Support implementation of Before-or-After actions; only one thread can

acquire the lock, the others have to wait.
All threads must obey the convention regarding the locks.
The two operations ACQUIRE and RELEASE must be atomic.
Hardware support for implementation of locks

ACQUIRE
RELEASE

RSM Read and Set Memory

CMP Compare and Swap

RSM (mem)

If mem=LOCKED then RSM returns r=LOCKED and sets mem=LOCKED

If mem=UNLOCKED the RSM returns r=LOCKED and sets mem=LOCKED

Lecture 18

Lecture 18

Lecture 18

10

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.

Lecture 18

11

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.

Lecture 18

12

Lecture 18

13

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

Lecture 18

14

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

Lecture 18

15

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, , Pn1 is waiting for a resource that is held by
Pn, and P0 is waiting for a resource that is held by P0.

Lecture 18

16

Wait for graphs

Lecture 18

17

Semaphores

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

Counting semaphore for an arbitrary resource count. Supports two operations:

V - signal() increments the semaphore C
P - wait() P decrements the semaphore C.

Binary semaphore: C is either 0 or 1.

Lecture 18

18

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;
}

Lecture 18

19

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

Lecture 18

20

Lecture 18

21

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 nished and returns, control goes back to where it came from

After receiving a signal, the receiver reacts to it in a well-dened 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.

Lecture 18

22

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.

Lecture 18

23