+ All Categories
Home > Documents > CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman [email protected].

CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman [email protected].

Date post: 20-Dec-2015
Category:
View: 219 times
Download: 0 times
Share this document with a friend
32
CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman [email protected]
Transcript
Page 1: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

CS444/CS544Operating Systems

Atomic Transactions

3/14/2007

Prof. Searleman

[email protected]

Page 2: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Outline

Deadlock Atomic Transactions

NOTE: Read: Chapter 8 HW#9 posted, due the Friday after break No lab on this Friday, 3/16

Page 3: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Recap: Methods for Handling Deadlock

Allow deadlock to occur, but…

Ignore it (ostrich algorithm)

Detection and recovery

Ensure that deadlock never occurs, by…

Prevention (negate at least 1 of the 4 necessary conditions for deadlock to occur)

Dynamic avoidance (be careful)

What are the consequences?

May be expensive

Constrains how requests for resources can be made

Processes must give maximum requests in advance

Page 4: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Deadlock avoidance

Say we don’t want to write the code such that it is impossible to deadlock -- could still prevent deadlock by having the system examine each request and only grant if deadlock can be avoided

Processes declare maximum resources they may ever request at the beginning

Then during execution, system will only grant a request if it can ensure that all processes can run to completion without deadlock

Page 5: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Grant a resource?

Consider a set of processes P1, P2, …Pn which each declare the maximum resources they might ever request

When Pi actually requests a resource, the system will grant the request only if the system could grant Pi’s maximum resource requests with the resource currently available plus the resources held by all the processes Pj for j != i

May need P1 to complete then P2 all the way to Pi but Pi can eventually complete

Page 6: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm

Decide whether to grant resource (loan or invest money, give a philosopher a chopstick, allow process to obtain a lock, …)

Let there be P processes and R resources Keep track of

Number of units of each resource available Maximum number of units of each resource that

each process could request Current allocation of each resource to each process

Page 7: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm

unsigned available[R];

unsigned allocation[P][R];

unsigned maximum[P][R];

startProcess(unsigned p){

for (i=0; i< R; i++){

maximum[p][i] = max number of resource i that process p will need at one time;

}

}

Page 8: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s AlgorithmBOOL request(unsigned p, unsigned r){

if (allocation[p][r] + 1 > maximum[p][r]){return FALSE; // p lied about its max

}

if (available[p][r] == 0){return FALSE; // no resource to grant

}

if (canGrantSafely(p, r))allocation[p][r]++;available[r]--;return TRUE;

} else {return FALSE;

}}

Page 9: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s AlgorithmBOOL canGrantSafely(unsigned p, unsigned r){

unsigned free[R]; unsigned canFinish[P];

for (j=0; j< R; j++) free[j] = available[j];for (i=0; i< P; i++) canFinish[i] = FALSE;

lookAtAll: for (i=0; i< P; i++){allCanFinish = TRUE; if (!canFinish[i])

allCanFinish = FALSE; couldGetAllResources = TRUE; for (j=0; j< R; j++){

if (maximum[i][j] - allocation[i][j] > free[j]){ couldGetAllResources = FALSE;

} }

if (couldGetAllResources){ canFinish[i] = TRUE; for (i=0; i< R; i++) free[j] += allocation[i][j];

} }} //for all processes (lookAtAll)

if (allCanFinish) {return TRUE;

}else {goto lookAtAll;

}}

Page 10: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm“State”

Resource A B C

Total # 10 5 7

Available 3 3 2

Current Allocation

A B C

p0 0 1 0

p1 2 0 0

p2 3 0 2

p3 2 1 1

p4 0 0 2

Still Needs

A B C

p0 7 4 3

p1 1 2 2

p2 6 0 0

p3 0 1 1

p4 4 3 1

Maximum Demand

A B C

7 5 3

3 2 2

9 0 2

2 2 2

4 3 3

Is the system currently in a safe state?

Page 11: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm“State”

Resource A B C

Total # 10 5 7

Available 3 3 2

Is the system currently in a safe state? To answer this, try to find any “safe sequence”.

<p1, p3, p4, p0, p2> is a safe sequence (there are others)

p1 can run to completion; it needs 1 A, 2Bs 2Cs which are available and can be given to it (leaving 2 As, 1B & 0Cs available). When p1 completes, it releases all of its resources: 3As, 2Bs & 2Cs. Now the system has available: 5 As, 3 Bs & 2 Cs

p3 can then run to completion

then run p4, p0 and p2.

Page 12: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm“State”

Resource A B C

Total # 10 5 7

Available 3 3 2

Current Allocation

A B C

p0 0 1 0

p1 2 0 0

p2 3 0 2

p3 2 1 1

p4 0 0 2

Still Needs

A B C

p0 7 4 3

p1 1 2 2

p2 6 0 0

p3 0 1 1

p4 4 3 1

Maximum Demand

A B C

7 5 3

3 2 2

9 0 2

2 2 2

4 3 3

Is the system currently in a safe state? Yes.

Now p1 requests 1A & 2Cs (1,0,2). Should the request be granted?

Page 13: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

P1 requests (1, 0, 2). Available (3, 3, 2)AVAILABLE ALLOCATION

p4 runs & requests (4, 3, 1) (3, 1, 2) p4 has (4, 3, 3)

p3 completes & releases all (7, 4, 3)

p1 granted (1,0,2) (2, 3, 0) p1 has (1, 1, 2)

p1 runs & requests (0,2,0) (2, 1, 0) p1 has (3, 2, 2)

p1 completes & releases all (5, 3, 2)

p3 runs & requests (0,1,1) (5, 2, 1) p3 has (2, 2, 2))

p4 completes & releases all (7, 4, 5)

p0 runs & requests (7, 4, 3) (0, 0, 2) p0 has (7, 5, 3)

p0 completes & releases all (7, 5, 5)

p2 runs & requests (6, 0, 0) (1, 5, 5) p2 has (9, 0, 2)

p2 completes & releases all (10, 5, 7)

Page 14: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm“State”

Resource A B C

Total # 10 5 7

Available 3 3 2

Current Allocation

A B C

p0 0 1 0

p1 2 0 0

p2 3 0 2

p3 2 1 1

p4 0 0 2

Still Needs

A B C

p0 7 4 3

p1 1 2 2

p2 6 0 0

p3 0 1 1

p4 4 3 1

Maximum Demand

A B C

7 5 3

3 2 2

9 0 2

2 2 2

4 3 3

p1 requests 1A & 2Cs (1,0,2). Should the request be granted? Yes. <p1, p3, p4, p0, p2) is a safe sequence

Page 15: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm“State”

Resource A B C

Total # 10 5 7

Available 3 3 2

Current Allocation

A B C

p0 0 1 0

p1 2 0 0

p2 3 0 2

p3 2 1 1

p4 0 0 2

Still Needs

A B C

p0 7 4 3

p1 1 2 2

p2 6 0 0

p3 0 1 1

p4 4 3 1

Maximum Demand

A B C

7 5 3

3 2 2

9 0 2

2 2 2

4 3 3

p0 requests (0, 4, 0). Grant request? No. There are not enough resources currently available (only 3 Bs).

Page 16: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm“State”

Resource A B C

Total # 10 5 7

Available 3 3 2

Current Allocation

A B C

p0 0 1 0

p1 2 0 0

p2 3 0 2

p3 2 1 1

p4 0 0 2

Still Needs

A B C

p0 7 4 3

p1 1 2 2

p2 6 0 0

p3 0 1 1

p4 4 3 1

Maximum Demand

A B C

7 5 3

3 2 2

9 0 2

2 2 2

4 3 3

p0 requests (0, 2, 2). Grant request? No. There are enough resources, but the resulting state is not safe (no one can run to completion, since available would be (3, 1, 0)).

Page 17: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Banker’s Algorithm

Note:

“unsafe state” ≠ “deadlocked state”

p0 can still run, and it might release some resources. Or it might never ask for its maximum demand. But you can’t guarantee that deadlock won’t occur.

=> Banker’s Algorithm is conservative

Page 18: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

If deadlock is not prevented

If don’t prevent deadlock - either through deadlock prevention or deadlock avoidance)- then how will the system deal with deadlock if (when!) it occurs:

Two choices Enable the system to detect deadlocks and if it does recover Hope they never happen and rely on manual detection and

recovery (“darn my process is hung again..kill process”)

Dining Philosophers? Force a philosopher to put down a chopstick = preemption Kill a philosopher? (sounds a bit brutal) Kill all philosophers?

Page 19: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Deadlock Detection

If don’t want to ever deny requests when have resources to grant them, then deadlock may occur

BOOL request(unsigned p, unsigned r){

if(available[p][r] > 0){

allocation[p][r]++;

available[r]--;

return TRUE;

} else {

return FALSE;

}

}

Page 20: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Deadlock Detection AlgorithmBOOL deadlockHasOccured(unsigned p, unsigned r) {

unsigned work[R]; unsigned canFinish[P];//initializationfor (j=0; j< R; j++) work[j] = available[j];for (i=0; i< P; i++){ numResourcesAllocated = 0; for (j=0; j< R; j++) { numResourcesAllocated += allocation[i][j]; } if (numResourcesAllocated == 0){ canFinish[i] = TRUE; //can’t be deadlocked if no hold + wait } else { canFinish[i] = FALSE; //don’t know if this one is deadlocked } }}

Page 21: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Deadlock Detection Algorithm tryToFinishOne: for (i=0; i< P; i++){ finishedSomeoneThisTime = FALSE; allFinished = TRUE;

if (!canFinish[i]){ allFinished = FALSE;

if ( (i != p) || (work[r] > 1) ) ) { canFinish[i] = TRUE;

finishedSomeoneThisTime = TRUE;for (j=0; j< R; j++) work[j] += allocation[i][j];

} }}if (allFinished){ return FALSE; //no deadlock} else {

if (! finishedSomeoneThisTime){ return TRUE; //deadlock for Pi s.t. canFinish[i] == FALSE } else { goto tryToFinishOne;

} } } //end deadlockHasOccured

Page 22: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Running deadlock detection?

Unlike deadlock avoidance, the detection algorithm have choice of when to run

Deciding how often How often is deadlock likely to occur? How many processes will be affected? When CPU utilization drops below X%?

Page 23: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Recovery from Deadlock

If system detects deadlock, what can it do to break the deadlock

What do people do after manual detection? Kill a process (es)

Pi s.t. canFinish[i] == FALSE Reboot the system

Page 24: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Recovering from deadlock How many?

Abort all deadlocked processes Abort one process at a time until cycle is

eliminated (If one doesn’t resolve deadlock, wait till deadlock detection algorithm runs again? Specifically run again with assumption that one of the processes is dead?)

Which ones? Lowest priority with canFinish = FALSE? One that has been running the least amount of

time (less work to redo) Process that hasn’t been killed before? Anyway to

tell?

Page 25: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Prevention vs Avoidance vs Detection Spectrum of low resource utilization

Prevention gives up most chances to allocate resources Detection always grants resource if they are available when

requested Also spectrum of runtime “overhead”

Prevention has very little overhead; programmer obeys rules and at runtime system does little

Avoidance uses banker’s algorithm (keep max request for each process and then look before leap)

Detection algorithm basically involves building the full resource allocation graph

Avoidance and detection algorithms both expensive! O(R*P2)

Page 26: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Real life?

Most used prevention technique is resource ordering – reasonable for programmers to attempt

Avoidance and Detection too expensive Most systems use manual detection and recovery

My process is hung – kill process My machine is locked up – reboot

Write code that deadlocks and run it on Linux and on Windows – what happens?

Page 27: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Atomic Transactions

Using Database Techniques

in Operating Systems

Page 28: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Definition: Atomic Transaction A transaction is a collection of instructions (or

operations) that perform a single logical function. Customer buys a car

MerchantsInventory-- Customer Bank Account -=PRICE Merchant Bank Account+=PRICE CustomerHistory++

All of these things should happen indivisibly – all or nothing? Even in the presence of failures and multiple concurrently executing transactions!

How do you make that happen when it is physically impossible to change all these things at the same time?

Page 29: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Commit/Abort

Introduce concept of commit (or save) at the end of a transaction

Until commit, all the individual operations that make up the transaction are pending

At any point before the transaction is committed, it might also be aborted

If a transaction is aborted, the system will undo or rollback the effects of any individual operations which have completed

Page 30: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

Database Systems Manage transactions (much like OSes manage

processes) Ensure the correct synchronization and the

saving of modified data on transaction commit Databases and OSes have a lot in common! Databases get a better roadmap

SQL queries provide up front map of transactions data access intentions

General processes change pattern based on user input and are not as structured in their data access specifications

Some OSes provide APIs for programs to declare their intentions

Page 31: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

ACID properties of Transactions (A)tomicity

Happen as a unit – all of nothing (C)onsistency

Integrity constraints on data are maintained (I)solation

Other transactions cannot see or interfere with the intermediate stages of a transaction

(D)urability Committed changes are reflected in the data permanently even in

the face of failures in the system Atomicity, consistency and isolation are all the result of

synchronization among transactions like the synchronization we have been studying between processes

Page 32: CS444/CS544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson.edu.

More on this after the break....

Have a good break!


Recommended