deadlock avoidance strategies lock priority …the bankers' algorithm is based upon the...

Deadlock avoidance strategiesLock priorityBanker's algorithm

Two problems with lock priority:� lack of transparency: application has to know that

locking has these properties� lack of handling of multiplicity: every resource has one

instance.

Deadlock avoidance Thursday, October 21, 20041:39 PM

Deadlock_avoidance

One issue in deadlock avoidance is application awareness; must the application be written differently in order to deal with what the OS does?� Transparent mechanisms: application doesn't need

to be rewritten. � Non-transparent mechanisms: application needs to

be aware of locking and unlocking behavior.

Problem: for lock priority mechanism to work, application must be aware that any lock can be broken during a wait for another lock, then relocked. Thus it is nottransparent.

Deadlock_avoidance

Basic tradeoff: transparency versus speed/performance of solution.� High transparency means relatively slow

throughput. � Low transparency allows more concurrency and

faster throughput.

Deadlock_avoidance

Banker's algorithm (Dijkstra)� Define a safe state as one in which deadlock cannot

occur.� Deny resource allocations when they will result in

an "unsafe" state in which a deadlock is possible.� Safety: there is a path of execution that does not

deadlock. � Key to algorithm: resource matrix

Banker's algorithm Thursday, October 21, 20042:05 PM

Deadlock_avoidance

Attributes of algorithm: � Paranoid and pessimistic: assumes the worst about

processes � Incremental: resource needs need not be known in

advance. � Transparent: processes do not need to know about

it.

Attributes of banker's algorithm Thursday, October 22, 200911:39 AM

Deadlock_avoidance

Basic idea of the banker's algorithmThe operating system is a banker.The banker loans resources to processes. The processes pay back the loan by returning the resources. Interest-free loans! :) Banker's goal is to assure that loans are paid back.

(this is not realistic for housing loans! :)

The banker Thursday, October 22, 200911:39 AM

Deadlock_avoidance

The banker is paranoid: The banker only gets payback on a loan if the client is able to complete the project, e.g., a housing development. But sometimes a client comes back for more money. The banker has to decide whether to grant it. The banker only grants the request if she'll still have enough money for all current loans to complete on some schedule.Otherwise, the banker says no!

Paranoia Thursday, October 22, 200911:44 AM

Deadlock_avoidance

Central concern for the banker is safetySafety is defined as a situation in which from the banker's point of view, some schedule allows all loans to be paid back. A situation is unsafe if there is no such schedule

Safety is paranoidAn unsafe situation does not necessarily deadlock. (there may be other factors than resources, e.g., a user could kill a process!) A safe situation can deadlock if a process doesn't complete (e.g., due to an infinite loop).

Safety Thursday, October 22, 200911:45 AM

Deadlock_avoidance

The bankers' algorithm is based upon the following (perhaps unfounded) assumptions:

Processes will be granted resources in the order in which they request them (first-come, first-serve). All processes are at the same priority for receiving resources. Processes that receive what they requested willcomplete and release resources. Processes that do not receive what they requested willnot complete and will continue to hold resources. Processes will not return resources until they receive all resources that they need.Processes are independent and do not collude.

These are closed-world assumptions. If processes lie, or are intelligent, the banker's algorithm doesn't work!

Assumptions Thursday, October 22, 200911:48 AM

Deadlock_avoidance

Resource matrices:� Rows: processes� Columns: resources� At row i, column j: demand or supply of

resource j by process i.

Resource matrices 2:05 PM

Deadlock_avoidance

Simple model: one resource = one column

One resource Thursday, October 21, 20042:05 PM

Deadlock_avoidance


A safe state Thursday, October 21, 20042:05 PM

Deadlock_avoidance


An unsafe state Thursday, October 21, 20042:05 PM

Deadlock_avoidance

The nature of safetySafety is a matter of the ability to complete tasks via first-come, first-serve resource grantingAn unsafe situation is one in which "too much money has been lent out for any schedule to exist".

What is unsafe? Thursday, October 22, 200912:15 PM

Deadlock_avoidance

Two resources

Two resources Thursday, October 21, 20042:05 PM

Deadlock_avoidance

Safety: � We are in a safe state(of allocation) if there is

a path to completion for all outstanding resource requests, where one request at a time is granted.

� Algorithm: � start with p processes, � choose one that can complete now, � put its resources back into the pool, � continue until you have no processes.

� If you can do this, you have a "safe" state.

But really important, we assume that: no process is fillibustering. all processes are independent. each process, given that its requests are granted, will complete.


Deadlock_avoidance

PracticalityOn the surface, it appears that we have to search for the appropriate schedule. We don't!

Dikjstra's observation: the position of a particular process in the completion sequence� only changes if its resource requirements

change. � moves toward front if requirements increase� moves toward back if requirements decrease

So we store the schedule and update it as resource requirements change!

Dijkstra's observation Thursday, October 22, 200912:24 PM

Deadlock_avoidance

Constraints and runtime� There must be a sequence of completions that results

in completing all processes. � Requires computing the sequence. � Computing the sequence takes O(n2) where n is the

number of processes: � for each process, if it can complete, complete it

and continue. � Each step requires O(n) and there are O(n) steps.

� But maintaining the sequence takes only O(n) per change, because processes only move back and forward when their requirements change.

� Thus we need O(n) steps per iteration after an initialization of O(n2) steps.


Deadlock_avoidance

Key to O(n) update: bubblesort the order. If one process Pi asks for one more unit, then

Order for other processes is still the same. Algorithm: swap Pi with Pi+1, Pi+2, etc, until you come to a process with more resource needs.

Bubblesort Thursday, October 21, 20042:05 PM

Deadlock_avoidance

Mathematical formulation:

Mathematical formulation Monday, October 17, 20053:17 PM

Deadlock_avoidance

Mathematical formulation continuedRij=process i's request for resource j.Gij=process i's current holdings of resource j.Dij=Rij-Gij=process i's deficit. Aj = number of jth resources available now. Tj = total number of jth resources available.

Basic constraint: For some process i,

For all resources j, Dij=Rij-Gij � Tj-�iGij=Aij


Deadlock_avoidance

Book's algorithm (page 272)

Starts with array of processes. While (possible) {

Find a process P[k] in array of processes, So that R[k,*]-G[k,*]=D[k,*]<= current available resources.

Compute what happens when that process finishes: Current available resources += current resources of PRemove P from set of processes.

}

Select one of n, O(n) remove from set, repeat until set empty. O(n)Total: O(n2) O(n2) = O(n+(n-1)+…+1)


Deadlock_avoidance

Real Banker's algorithmFind and store an initial order in which processes can finish. O(n2). When a resource is granted, that affects the position of the process in the order. (order of other processes doesn't change)So: try the possible new positions for the one process that changed.


Deadlock_avoidance

Banker's algorithm assumes that� All processes run in good faith, and will complete if

granted their resource requests. � No process does anything special to avoid deadlock

other than running to completion.� processes are independent other than resource needs.

Subtleties Monday, October 17, 20053:10 PM

Deadlock_avoidance

Caveats� An unsafe state is not a deadlock.

It is simply a state in which a deadlock is possible unless some outside force intervenes (such as, e.g., a process changing its mind and completing without getting resources.

� A system in an unsafe state can recover without deadlock. E.g., if some outside force intervenes.Banker's algorithm presumes that this will not happen, and is overly conservative.

� This is not true, e.g., for web services: clients can close connections from outside, breaking resource deadlocks.

Caveats Thursday, October 22, 200912:35 PM

Deadlock_avoidance

Given: � A set of services with desired response times. � A farm of servers that will answer requests. � A resource model for what it means to satisfy a

request. Provide: � A yes/no decision as to whether to "admit" each

request as a job.� Based upon avoiding server resource saturation

(deadlock caused when too many requests enter the queue).

Admission control Monday, October 17, 20053:15 PM

Deadlock_avoidance

Service-level agreement: � An agreement between a resource provider and a

client that determines "how fast" resource requirements should be met.

� Typical: "web page should load in 1/2 second or less". "Search should take at most 10 seconds." Etc.

� Purpose of service-level agreements: relate performance to business gain/loss.

Response time and sales� Brutal truth: response time relates to sales.

� < 10 seconds for search -> sale. � > 10 seconds for search -> no sale. � even partial slowdowns cost millions.

� Reciprocal charges: if you don't meet SLA, and cost customer sales, they don't pay you as much!

SLA's and operating systems� Time in system for a request is related to resource

availability: � CPU cycles� Disk I/O� Memory availability (physical and virtual)

� Too many simultaneous requests -> won't meet SLA.

Deadlock_avoidance

Admission control caveats� Survey data: if you don't respond to a travelocity

search request within 10 seconds, travelocity has lost the sale.

� If you don't meet the service agreement, might as well not complete at all.

� So if the system is close to saturation, don't admit more requests; simply drop them.

� This allows some requests to satisfy SLA even if some get dropped; the result is maximum income.

Deadlock_avoidance

Modelling admission control: � Each request takes

� some memory (fork). � some disk I/O.

� Total memory is a constant (resource A). � Total disk I/O possible in 10 seconds is approximately

constant (resource B).� A system is in an unsafe state if it is saturated to the

point where potentially there is a deadlock waiting for resources.

� Each request is categorized as to � The amount of memory it requires. � The amount of disk I/O to do.

� Achieving safety means that the SLA will be met for admitted jobs.

Caveat: safety can be anything you want.

One can define resource saturation as anything one wants (in this case, responding to an SLA) and ensure that there is no possibility of violating the SLA.

Deadlock_avoidance

Admission control notes� The control mechanism is external to the OS of the

systems doing the service. � They are protected "from outside" by controlling what

inputs they get. � Does not take varying conditions (e.g. disk slowdown

due to hardware failure) into account. � Model of deadlock is approximate and at best

conservative.

Admission control notes Monday, October 17, 20053:26 PM

Deadlock_avoidance

deadlock avoidance strategies lock priority …the bankers' algorithm is based upon the...

Documents