CS703 - Advanced Operating Systems By Mr. Farhan Zaidi

Lecture No. 13

Overview of today’s lecture Deadlocks Definition Four necessary and sufficient conditions Examples Detection Avoidance Prevention Current practice

Formal definition of a deadlock A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause Usually the event is release of a currently held resource None of the processes can … run release resources be awakened

Resource graph

Conditions for deadlock Without all of these, can't have deadlock: 1. Mutual exclusion (for example: mutex on bounded buffer) 2. No preemption (if someone has resource, can't take it away) 3. Hold and wait 4. Circular wait

Deadlock example /* transfer x dollars from a to b */ Given two threads, what sequence of calls cause the following to deadlock? /* transfer x dollars from a to b */ void transfer(account *a, account *b, int x) P (a - > sema); P (b - > sema): a - > balance += x; b - > balance -= x; V (a - > sema); V ( b - > sema);

Deadlocks don’t require synch primitives Does deadlock require locks? No. Just circular constraints. Example: consider two threads that send and receive data to each other using two circular buffers (buf size = 4096 bytes). Recall: a full buffer causes the sender to block until the receiver removes data. T1: T2: send n bytes to T2 while(receive 4K of data) ; process data while(receive data) send 4K result to T1 display data exit exit

Solutions to Deadlock Detect deadlock and fix scan graph detect cycles fix them // this is the hard part! a) Shoot thread, force it to give up resources. This isn't always possible -- for instance, with a mutex, can't shoot a thread and leave world in an inconsistent state. b) Roll back actions of deadlocked threads (transactions) Common technique in databases

Transactions and two phase commit Acquire all resources, if block on any, release all, and retry Printfile: lock-file lock-printer lock-disk do work release all Pro: dynamic, simple, flexible Con: cost with number of resources? length of critical section? hard to know what’s needed a priori

Preventing deadlock Need to get rid of one of the four conditions. a) No sharing -- totally independent threads. b) Preempt resources c) Make all threads request and reserve everything they'll need at beginning Problem is -- predicting future is hard, tend to over-estimate resource needs (inefficient)

Banker's algorithm More efficient than reserving all resources on startup State maximum resource needs in advance Allocate resources dynamically when resource is needed Wait if granting request would lead to deadlock (request can be granted if some sequential ordering of requests is deadlock free) Bankers algorithm allows the sum of maximum resource needs of all current threads to be greater than the total resources, as long as there is some way for all the threads to finish without getting into deadlock. For example, you can allow a thread to proceed if the total available resources - # allocated >= max remaining that might be needed by this thread. In practice, Banker’s algorithm is rarely used since ir requires predicting maximum resource requirements in advance.

Resource ordering Make everyone use the same ordering in accessing resources. For example, all threads must grab semaphores in the same order

Current practice Microsoft SQL Server “The SQL Server Database Engine automatically detects deadlock cycles within SQL Server. The Database Engine chooses one of the sessions as a deadlock victim and the current transaction is terminated with an error to break the deadlock.” Oracle As Microsoft SQL Server, plus “Multitable deadlocks can usually be avoided if transactions accessing the same tables lock those tables in the same order... For example, all application developers might follow the rule that when both a master and detail table are updated, the master table is locked first and then the detail table.”

Windows internals (Linux no different) “Unless they did a huge change in Vista, the NT kernel architecture is a deadlock minefield. With the multi-threaded re-entrant kernel there is plenty of deadlock potential.” “Lock ordering is great in theory, and NT was originally designed with mutex levels, but they had to be abandoned. Inside the NT kernel there is a lot of interaction between memory management, the cache manager, and the file systems, and plenty of situations where memory manager acquires its lock and then calls the cache manager. This happens while the file system calls the cache manager to fill the cache which in turn goes through the memory manager to fault in its page. And the list goes on.”