CS 444CS 544 Operating Systems Atomic Transactions 3142007

CS 444/CS 544 Operating Systems Atomic Transactions 3/14/2007 Prof. Searleman jets@clarkson. edu

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

Recap: Methods for Handling Deadlock l l Allow deadlock to occur, but… l Ignore it (ostrich algorithm) What are the consequences? l Detection and recovery May be expensive Ensure that deadlock never occurs, by… l Prevention (negate at least 1 of the 4 necessary conditions for deadlock to occur) Constrains how requests for resources can be made l Dynamic avoidance (be careful) Processes must give maximum requests in advance

Deadlock avoidance l l l 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

Grant a resource? l l l Consider a set of processes P 1, P 2, …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 P 1 to complete then P 2 all the way to Pi but Pi can eventually complete

Banker’s Algorithm l l l 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 l l l 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

Banker’s Algorithm unsigned available[R]; unsigned allocation[P][R]; unsigned maximum[P][R]; start. Process(unsigned p){ for (i=0; i< R; i++){ maximum[p][i] = max number of resource i that process p will need at one time; } }

Banker’s Algorithm BOOL 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 (can. Grant. Safely(p, r)) allocation[p][r]++; available[r]--; return TRUE; } else { return FALSE; } }

Banker’s Algorithm BOOL can. Grant. Safely(unsigned p, unsigned r){ unsigned free[R]; unsigned can. Finish[P]; for (j=0; j< R; j++) free[j] = available[j]; for (i=0; i< P; i++) can. Finish[i] = FALSE; if (all. Can. Finish) { return TRUE; }else { goto look. At. All; } look. At. All: for (i=0; i< P; i++){ all. Can. Finish = TRUE; } if (!can. Finish[i]) all. Can. Finish = FALSE; could. Get. All. Resources = TRUE; for (j=0; j< R; j++){ if (maximum[i][j] - allocation[i][j] > free[j]){ could. Get. All. Resources = FALSE; } } if (could. Get. All. Resources){ can. Finish[i] = TRUE; for (i=0; i< R; i++) free[j] += allocation[i][j]; } } } //for all processes (look. At. All)

Banker’s Algorithm “State” Current Allocation Resource A B C Total # 10 5 7 Available 3 2 Maximum Demand A B C p 0 0 1 0 7 5 3 p 1 2 0 0 3 2 p 2 3 0 2 9 p 3 2 1 1 p 4 0 0 2 3 Still Needs A B C p 0 7 4 3 2 p 1 1 2 2 0 2 p 2 6 0 0 2 2 2 p 3 0 1 1 4 3 3 p 4 4 3 1 Is the system currently in a safe state?

Banker’s Algorithm “State” Resource A B C Total # 10 5 7 Available 3 2 3 Is the system currently in a safe state? To answer this, try to find any “safe sequence”. <p 1, p 3, p 4, p 0, p 2> is a safe sequence (there are others) p 1 can run to completion; it needs 1 A, 2 Bs 2 Cs which are available and can be given to it (leaving 2 As, 1 B & 0 Cs available). When p 1 completes, it releases all of its resources: 3 As, 2 Bs & 2 Cs. Now the system has available: 5 As, 3 Bs & 2 Cs p 3 can then run to completion then run p 4, p 0 and p 2.

Banker’s Algorithm “State” Current Allocation Resource A B C Total # 10 5 7 Available 3 2 Maximum Demand A B C p 0 0 1 0 7 5 3 p 1 2 0 0 3 2 p 2 3 0 2 9 p 3 2 1 1 p 4 0 0 2 3 Still Needs A B C p 0 7 4 3 2 p 1 1 2 2 0 2 p 2 6 0 0 2 2 2 p 3 0 1 1 4 3 3 p 4 4 3 1 Is the system currently in a safe state? Yes. Now p 1 requests 1 A & 2 Cs (1, 0, 2). Should the request be granted?

P 1 requests (1, 0, 2). Available (3, 3, 2) AVAILABLE ALLOCATION p 1 granted (1, 0, 2) (2, 3, 0) p 1 has (1, 1, 2) p 1 runs & requests (0, 2, 0) (2, 1, 0) p 1 has (3, 2, 2) p 1 completes & releases all (5, 3, 2) p 3 runs & requests (0, 1, 1) (5, 2, 1) p 3 completes & releases all (7, 4, 3) p 4 runs & requests (4, 3, 1) (3, 1, 2) p 4 completes & releases all (7, 4, 5) p 0 runs & requests (7, 4, 3) (0, 0, 2) p 0 completes & releases all (7, 5, 5) p 2 runs & requests (6, 0, 0) (1, 5, 5) p 2 completes & releases all (10, 5, 7) p 3 has (2, 2, 2)) p 4 has (4, 3, 3) p 0 has (7, 5, 3) p 2 has (9, 0, 2)

Banker’s Algorithm “State” Current Allocation Resource A B C Total # 10 5 7 Available 3 2 Maximum Demand A B C p 0 0 1 0 7 5 3 p 1 2 0 0 3 2 p 2 3 0 2 9 p 3 2 1 1 p 4 0 0 2 3 Still Needs A B C p 0 7 4 3 2 p 1 1 2 2 0 2 p 2 6 0 0 2 2 2 p 3 0 1 1 4 3 3 p 4 4 3 1 p 1 requests 1 A & 2 Cs (1, 0, 2). Should the request be granted? Yes. <p 1, p 3, p 4, p 0, p 2) is a safe sequence

Banker’s Algorithm “State” Current Allocation Resource A B C Total # 10 5 7 Available 3 2 Maximum Demand A B C p 0 0 1 0 7 5 3 p 1 2 0 0 3 2 p 2 3 0 2 9 p 3 2 1 1 p 4 0 0 2 3 Still Needs A B C p 0 7 4 3 2 p 1 1 2 2 0 2 p 2 6 0 0 2 2 2 p 3 0 1 1 4 3 3 p 4 4 3 1 p 0 requests (0, 4, 0). Grant request? No. There are not enough resources currently available (only 3 Bs).

Banker’s Algorithm “State” Current Allocation Resource A B C Total # 10 5 7 Available 3 2 Maximum Demand A B C p 0 0 1 0 7 5 3 p 1 2 0 0 3 2 p 2 3 0 2 9 p 3 2 1 1 p 4 0 0 2 3 Still Needs A B C p 0 7 4 3 2 p 1 1 2 2 0 2 p 2 6 0 0 2 2 2 p 3 0 1 1 4 3 3 p 4 4 3 1 p 0 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)).

Banker’s Algorithm l Note: “unsafe state” ≠ “deadlocked state” p 0 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

If deadlock is not prevented l l 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 l l l 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? l l l Force a philosopher to put down a chopstick = preemption Kill a philosopher? (sounds a bit brutal) Kill all philosophers?

Deadlock Detection l 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; } }

Deadlock Detection Algorithm BOOL deadlock. Has. Occured(unsigned p, unsigned r) { unsigned work[R]; unsigned can. Finish[P]; //initialization for (j=0; j< R; j++) work[j] = available[j]; for (i=0; i< P; i++){ num. Resources. Allocated = 0; for (j=0; j< R; j++) { num. Resources. Allocated += allocation[i][j]; } if (num. Resources. Allocated == 0){ can. Finish[i] = TRUE; //can’t be deadlocked if no hold + wait } else { can. Finish[i] = FALSE; //don’t know if this one is deadlocked } }}

Deadlock Detection Algorithm try. To. Finish. One: for (i=0; i< P; i++){ finished. Someone. This. Time = FALSE; all. Finished = TRUE; if (!can. Finish[i]){ all. Finished = FALSE; if ( (i != p) || (work[r] > 1) ) ) { can. Finish[i] = TRUE; finished. Someone. This. Time = TRUE; for (j=0; j< R; j++) work[j] += allocation[i][j]; } } } if (all. Finished){ return FALSE; //no deadlock } else { if (! finished. Someone. This. Time){ return TRUE; //deadlock for Pi s. t. can. Finish[i] == FALSE } else { goto try. To. Finish. One; } } } //end deadlock. Has. Occured

Running deadlock detection? l l Unlike deadlock avoidance, the detection algorithm have choice of when to run Deciding how often l l l How often is deadlock likely to occur? How many processes will be affected? When CPU utilization drops below X%?

Recovery from Deadlock l l If system detects deadlock, what can it do to break the deadlock What do people do after manual detection? l Kill a process (es) l l Pi s. t. can. Finish[i] == FALSE Reboot the system

Recovering from deadlock l How many? l l l 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? l l l Lowest priority with can. Finish = 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?

Prevention vs Avoidance vs Detection l Spectrum of low resource utilization l l l Prevention gives up most chances to allocate resources Detection always grants resource if they are available when requested Also spectrum of runtime “overhead” l l 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*P 2)

Real life? l l l Most used prevention technique is resource ordering – reasonable for programmers to attempt Avoidance and Detection too expensive Most systems use manual detection and recovery l l l 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?

Atomic Transactions Using Database Techniques in Operating Systems

Definition: Atomic Transaction l l A transaction is a collection of instructions (or operations) that perform a single logical function. Customer buys a car l l l Merchants. Inventory-Customer Bank Account -=PRICE Merchant Bank Account+=PRICE Customer. History++ 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?

Commit/Abort l l 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

Database Systems l l 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 l l l 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

ACID properties of Transactions l (A)tomicity l l (C)onsistency l l Other transactions cannot see or interfere with the intermediate stages of a transaction (D)urability l l Integrity constraints on data are maintained (I)solation l l Happen as a unit – all of nothing 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

More on this after the break. . Have a good break!