WEEK 3

SCHEDULING POLICIESSYNCHRONIZATION

DEADLOCKS

Operating SystemsCS3013 / CS502

Agenda

Scheduling Policies

Synchronization

Deadlock

2

Objectives3

Identify Scheduling Criteria

Explain Different Scheduling Policies

Describe Measurements for Evaluation

Give Examples of Evaluation Methods

CPU Burst Duration4

Scheduler5

Invoked whenever the operating system must select a user-level process to execute After process creation/termination A process blocks on I/O I/O interrupt occurs Clock interrupt occurs

Type of processes Interactive jobs CPU bound jobs Somewhere inbetween

Scheduling Criteria6

What should we consider in developing a scheduling policy?

Scheduling Criteria7

CPU Utilization – keep the CPU as busy as possible

Throughput - # of processes that complete their execution per time unit

Turnaround time – amount of time to execute a particular process

Waiting time – amount of time process has been waiting in the ready queue

Response time – amount of time from request submission until first response is produced

Scheduling Issues8

Fairness – don’t starve process

Priorities – most important first

Deadlines – task X must be done by time t

Optimization – throughput, response time, etc.

Scheduling Evaluation9

Simplicity – easy to implementJob latency – time from start to completionInteractive latency – time from action start to

expected system responseThroughput – number of jobs completedUtilization – keep processor and/or subset of

I/O devices busyDeterminism – insure that jobs get done

before some time or eventFairness – every job makes progress

Policies10

First-Come-First-Serve (FCFS)

Round Robin

Shorted Process/Job First (SPF/SJF)

Pre-emptive Shorted Process/Job First (PSPF/PSJF)

Multiple-level Feedback (FB)

First-Come-First-Serve (FCFS)11

Process Burst Time

A 5

B 7

C 3

A CB

0 5 12 15

Shortest Process/Job First12

Process Burst Time

A 5

B 7

C 3

AC B

0 3 8 15

Exponential Average13

b(t+1) = a b(t) + (1-a) b(t)

a=0 Current value has no effect

a=1 Only current value matters

b(0) = system average, a=0.5

Priority Scheduling14

Process Burst Time Priority

A 5 3

B 7 1

C 3 2

ACB

0 7 10 15

Priority Scheduling Issues15

Starvation – low priority processes may never execute Use of aging

Priority Inversion – some processes may never run to release resources required by other processes Increase the priority to match level of resource of

level of waiting process

Round Robin16

Process Burst Time

A 5

B 7

C 3

A A A A AC C CB B B B BB B

0 9 12 15

Round Robin17

Play with Quantum q = 1 q = 2 q = 5

Process Burst Time

A 5

B 7

C 3

Round Robin18

Avg. Turnaround Time Quantum from 1 to 5 How does it change?

Process Burst Time

A 5

B 3

C 1

D 7

Exercise19

Process Burst Time Priority

A 10 2

B 1 1

C 2 3

Exercise20

Turnaround time FCFS SJF (Preemptive vs. Non-preemptive) RR q= 1 RR q = 0.5

Process Arrival Time Burst Time

A 0.0 8

B 0.4 4

C 1.0 1

Multilevel Queues21

Multilevel Ready Queue Foreground (interactive) Background (batch)

Each queue has its own scheduling algorithm Foreground – RR Background – FCFS

Scheduling between queues is required Fixed priority scheduling Time slice

Multilevel Feedback Queue22

Process can move between queues

Parameters # of queues Scheduling algorithm for each queue Method to determine when to upgrade a process Method to determine when to demote a process Method to determine which queue a process will enter

when that process needs service

Objectives23

Identify Scheduling Criteria

Explain Different Scheduling Policies

Describe Measurements for Evaluation

Give Examples of Evaluation Methods

Agenda24

Objectives25

Explain reasons for synchronization

Describe busy waiting solutions

Describe a semaphore and its use

Describe a sonitor and its use

Why synchronization?26

Time John Jane

3:00 Look in fridge. Oh no, no pizza!

3:05 Leave for store. Look in fridge. Oh no, no pizza!

3:10 Arrive at store. Leave for store.

3:15 Buy pizza. Arrive at store.

3:20 Arrive home. Buy pizza.

3:25 Put away pizza. Arrive home.

3:30 Put away pizza.

Oh no!

Cooperating Processes27

Consider a printer spooler Enter a file name into the spooler queue Printer daemon checks the queue and prints the file.

“Race Conditions”

Free 9

letter hw1 proj1 lecture1

5 76 8 9

A B

Race Condition Demo28

Shared variableOne program increments the shared variable.The other decrements the shared variable.

// reads the value of shared memorysscanf(counter, "%d", &num);// incrememt/decrement the numbernum = num + incr;// writes the new value to the shared memorysprintf(counter, "%d\n", num);

Producer / Consumer29

Model for cooperating processes

Producer “produces” an item that consumer “consumes”

Bounded buffer (shared memory)

item buffer[MAX]; /* queue */int counter; /* number of items */

Producer30

item i; /* item produced */int in; /* put next item */while (1) {

produce an item;while (counter == MAX) {/* no-op */}buffer[in] = item;in = (in + 1) % MAX;counter = counter + 1;

}

Consumer31

item i; /* item consumed */int out; /* take next item */while (1) {

while (counter == 0) {/* no-op */}item = buffer[out]out = (out + 1) % MAX;counter = counter - 1;

}

Producer Consumer Trouble!32

P R1 = counter R1 = 5

P R1 = R1 + 1 R1 = 6

C R2 = counter R2 = 5

C R2 = R2 – 1 R2 = 4

C counter = R2 counter = 4

P counter = R1 counter = 6

Critical Section33

Mutual Exclusion Only one process inside critical region

Progress No process outside critical region may block other

processes wanting in

Bounded Waiting No process should have to wait forever (starvation)

First Try34

Shared variable turn is initialized to either A or B and both processes start execution concurrently.

…While (TRUE) {

…while (turn == B) ;// critical sectionturn = B;…

}

…While (TRUE) {

…while (turn == B) ;// critical sectionturn = B;…

}

…While (TRUE) {

…while (turn == A) ;// critical sectionturn = A;…

}

…While (TRUE) {

…while (turn == A) ;// critical sectionturn = A;…

}

Process A Process B

Second Try35

Shared variables pAinside and pBinside are initialized to FALSE.

…While (TRUE) {

…while (pBinside) ;pAinside = TRUE;// critical sectionpAinside = FALSE;…

}

…While (TRUE) {

…while (pBinside) ;pAinside = TRUE;// critical sectionpAinside = FALSE;…

}

…While (TRUE) {

…while (pAinside) ;pBinside = TRUE;// critical sectionpBinside = FALSE;…

}

…While (TRUE) {

…while (pAinside) ;pBinside = TRUE;// critical sectionpBinside = FALSE;…

}

Process A Process B

Third Try36

Shared variables pAtrying and pBtrying are initialized to FALSE.

…While (TRUE) {

…pAtrying = TRUE;while (pBtrying) ;// critical sectionpAtrying = FALSE;…

}

…While (TRUE) {

…pAtrying = TRUE;while (pBtrying) ;// critical sectionpAtrying = FALSE;…

}

…While (TRUE) {

…pBtrying = TRUE;while (pAtrying) ;// critical sectionpBtrying = FALSE;…

}

…While (TRUE) {

…pBtrying = TRUE;while (pAtrying) ;// critical sectionpBtrying = FALSE;…

}

Process A Process B

Dekker’s Algorithm37

turn needs to be initialized to A or B.

…While (TRUE) { … pAtrying = TRUE; while (pBtrying)

if (turn == B) { pAtrying = FALSE; while (turn == B) ; pAtrying = TRUE;}

// critical section turn = B; pAtrying = FALSE; …}

…While (TRUE) { … pAtrying = TRUE; while (pBtrying)

if (turn == B) { pAtrying = FALSE; while (turn == B) ; pAtrying = TRUE;}

// critical section turn = B; pAtrying = FALSE; …}

Process A Process B…While (TRUE) { … pBtrying = TRUE; while (pAtrying)

if (turn == A) { pBtrying = FALSE; while (turn == A) ; pBtrying = TRUE;}

// critical section turn = A; pBtrying = FALSE; …}

…While (TRUE) { … pBtrying = TRUE; while (pAtrying)

if (turn == A) { pBtrying = FALSE; while (turn == A) ; pBtrying = TRUE;}

// critical section turn = A; pBtrying = FALSE; …}

Peterson’s Algorithm38

turn does not need any initialization.

…While (TRUE) { … pAtrying = TRUE; turn = B; while (pBtrying && turn == B); // critical section pAtrying = FALSE; …}

…While (TRUE) { … pAtrying = TRUE; turn = B; while (pBtrying && turn == B); // critical section pAtrying = FALSE; …}

Process A Process B…While (TRUE) { … pBtrying = TRUE; turn = A; while (pAtrying && turn == A); // critical section pBtrying = FALSE; …}

…While (TRUE) { … pBtrying = TRUE; turn = A; while (pAtrying && turn == A); // critical section pBtrying = FALSE; …}

Dekker’s and Peterson’s Algorithm39

Both of them are correct.

Limited to 2 processes

Can be generalized to N processes N must be known and fixed. Algorithm becomes too complicated and expensive.

Synchronization Hardware40

Test-and-Set: returns and modifies atomically

int Test_and_Set(int &target) {int temp;temp = target;target = true;return temp;

}

Using Test_and_Set41

All solutions so far requires “busy waiting”.

while (1) {while (Test_and_Set(lock)) ;// critical sectionlock = false;// remainder section

}

Semaphore42

Semaphore43

Do not require “busy waiting”Semaphore S (shared, often initially = 1)

Integer variable Accessed via two (indivisible) atomic operations

wait(S) : S = S – 1if (S < 0) then block(S)

signal(S) : S = S + 1;if (S <= 0) then wakeup(S)

Critical Section with Semaphore44

semaphore mutex; /* shared */

while (1) {wait(mutex);// critical sectionsignal(mutex);// remainder section

}

Classical Synchronization Problems45

Bounded Buffers

Readers/Writers

Dining Philosophers

Readers/Writers46

Readers can only read the content

Writers read and write the object

Critical Region One or more readers (no writers) One writer (nothing else)

Solutions favor Reader or Writer

Readers/Writers47

Shared

Writer

semaphore mutex, wrt;int readcount;

wait(wrt);// write stuffsignal(wrt)

Reader

Readers-Writers48

wait(mutex);readcount = readcount + 1;if (readcount == 1) wait(wrt);signal(mutex);// read stuffwait(mutex);readcount = readcount – 1;if (readcount == 0) signal(wrt);signal(mutex);

Dining Philosophers49

Philosophers Think Eat

Need 2 chopsticks to eat

Dining Philosophers50

Philosopher i

while (1) {// thinkwait(chopstick[i]);wait(chopstick[i+1 % 5]);// eatsignal(chopstick[i]);signal(chopstick[i+1 % 5]);

}

Dining Philosophers51

Other solutions

Allow at most N-1 to go hungry at a time

Allow to pick up chopsticks only if both are available

Asymmetric solution

Monitors52

High-level constructCollection of

Variables Data structures Functions Like C++ class

One process active inside“Condition” variable

Not like semaphore

Producer-Consumer Monitor53

monitor ProducerConsumer {condition full, empty;integer count;

// functionsvoid enter(item i);item remove();

}

void producer();void consumer();

Producer-Consumer Monitor54

void producer() {item i;while (1) {

// produce item iProducerConsumer.enter(i);

}}void consumer() {

item i;while (1) {

i = ProducerConsumer.remove();// consume item i

}}

Producer-Consumer Monitor55

void enter(item i) {if (count == N) sleep(full);// add item icount = count + 1;if (count == 1) then wakeup(empty);

}void remove() {

if (count == 0) then sleep(empty);// remove item into icount = count – 1;if (count == N-1) then wakeup(full);return i;

}

Objectives56

Explain reasons for synchronization

Describe busy waiting solutions

Describe a semaphore and its use

Describe a sonitor and its use

Agenda57

Objectives58

Identify deadlocks

Describe ways to prevent deadlocks

Describe ways to detect deadlocks

Describe ways to recover from deadlocks

Deadlock59

Examples “It takes money to make money” You can’t get a job without experience; you can’t get

experience without a job.

Background The cause of deadlocks: Each process needing what

another process has. This results from sharing resources such as memory, devices, links.

Under normal operation, a resource allocation proceeds like this: Request a resource (suspend until available if necessary) Use the resource Release the resource

Conditions for Deadlock60

Mutual Exclusion Each resource is assigned to a process or is available

Hold and Wait Processes holding resources can request new

resources

No Preemption Resources cannot be taken from a process

Circular Wait A set of processes are in a circular wait

Resource Allocation Graph61

G = (V, E)

V : Nodes consist of processes and resource types

E : Edges are pairs of processes and resources

PiRj

PiRj

Pi

No cycle No deadlock Cycle

If resource types have multiple instances, then deadlock MAY exist

If each resource type has 1 instance, then deadlock has occurred

Resource Allocation Graph62

P2 Requests P3

R3 Assigned to P3

Resource Allocation Graph63

Handling Deadlocks64

Ignore Deadlocks

Ensure deadlock never occurs Prevention Avoidance

Allow deadlock to happen Detection Recovery

Deadlock Prevention65

Mutual Exclusion Not really possible

Hold and Wait Collect all resources before execution Only request resource when no others are being held

No Preemption Release any resource being held if the process can’t

get additional resource Allow preemption

Circular Wait Number resources and only request in ascending

order

Deadlock Avoidance66

Possible States Deadlock: No forward progress can be made Unsafe: A state that may cause deadlock Safe: A state is safe if a sequence of processes exist

such that there are enough resources for the first to finish, and as each finishes and releases its resources there are enough for the next to finish.

If a request allocation would cause an unsafe state, do not honor that request.

Deadlock Detection67

Resource Allocation Graph Wait-for Graph

Deadlock Recovery68

PROCESS TERMINATION: Could delete all the processes in the deadlock -- this is expensive. Delete one at a time until deadlock is broken ( time consuming ). Select who to terminate based on priority, time executed, time to

completion, needs for completion, or depth of rollback In general, it's easier to preempt the resource, than to terminate

the process.

RESOURCE PREEMPTION:  Select a victim - which process and which resource to preempt. Rollback to previously defined "safe" state. Prevent one process from always being the one preempted

( starvation ).