Operating Systems CSE 411

1. Operating SystemsCSE 411 Kernel synchronization, deadlocks Dec. 11 2006 - Lecture 31 Instructor: Bhuvan Urgaonkar

2. Symmetric Multi-threading • Idea: Create multiple virtual processors on a physical processor • Illusion provided by hardware • Called hyper-threading in Intel machines • The OS sees the machine as an SMP • Each virtual processor has its own set of registers and interrupt handling, cache is shared • Why: Possibility of better parallelism, better utilization • How does it concern the OS? • From a correctness point of view: it does not • From an efficiency point of view: the scheduler could exploit it to do better load balancing

3. Synchronization in SMPs&Kernel Synchronization

4. Synchronization building blocks: Atomic Instructions • An atomic instruction for a uni-processor would not be atomic on an SMP unless special care is taken • In particular, any atomic instruction needs to write to a memoy location • Recall TestAndSet, Swap • Need special support from the hardware • Hardware needs to ensure that when a CPU writes to a memory location as part of an atomic instruction, another CPU can not write the same memory location till the first CPU is finished with its write • Given above hardware support, OS support for synchronization of user processes same as in uni-processors • Semaphores, monitors • Kernel synchronization raises some special considerations • Both in uni- and multi-processors

5. Kernel Control Path • Recall: A kernel is a “server” that answers requests issued in two possible ways • A process causes an exception (E.g., page fault, system call) • An external device sends an interrupt • Definition: Kernel Control Path • The set of instructions executed in the kernel mode to handle a kernel request • Similar to a process, except much more rudimentary • No descriptor of any kind • Most modern kernels are “re-entrant” => Multiple KCPs may be executing simultaneously • Synchronization problems can occur if two KCPs update the same data • How to synchronize KCP access to shared data/resources?

6. Two mechanisms for easy to achieve kernel synchronization • Non-preemptible kernel design • A KCP can not be pre-empted by another one • Useful only for certain KCPs, such as those that have no synch. issues with interrupt handlers • Not enough for multi-processors since multiple CPUs can concurrently access the same data structure • Adopted by many OSes including versions of Linux upto 2.4 • Linux 2.6 is pre-emptible: faster dispatch times for user processes • Interrupt disabling • Disable all hardware interrupts before entering a critical section and re-enable them right after leaving it • Works for uni-processor in certain situations • The critical section should not incur an exception whose handler has synchronization issues with it • The CS should not get blocked • What if the CS incurs a page fault? • Does not work for multi-processors

7. How to synchronize KCP access to shared data? • Can use semaphores or monitors • Not always the best solution in multi-processors • Consider two KCPs running on different CPUs • If the time to update a shared data structure is very short, then semaphores may be an overkill • Solution: Spin Locks • Do busy wait instead of getting blocked! • The kernel designers must decide when to use spin locks versus semaphores • Spin locks are useless in uni-processors: Why?

8. Deadlocks

9. The Deadlock Problem • A set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set. • Example • System has 2 disk drives. • P1 and P2 each hold one disk drive and each needs another one. • Example • semaphores A and B, initialized to 1 P0P1 wait (A); wait(B) wait (B); wait(A)

10. Bridge Crossing Example • Traffic only in one direction. • Each section of a bridge can be viewed as a resource. • If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback). • Several cars may have to be backed up if a deadlock occurs. • Starvation is possible.

11. Deadlock and starvation • Deadlock implies starvation but not the other way around • Recall Dining Philosophers

12. System Model • Resource types R1, R2, . . ., Rm CPU cycles, memory space, I/O devices • Each resource type Ri has Wi instances. • Each process utilizes a resource as follows: • request • use • release

13. Deadlock Characterization Deadlock can arise if four conditions hold simultaneously: Note: Necessary conditions but not sufficient • Mutual exclusion: only one process at a time can use a resource. • No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task. • Circular wait: there exists a set {P0, P1, …, Pn} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and Pn is waiting for a resource that is held by P0 => Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes.

14. Resource-Allocation Graph A set of vertices V and a set of edges E. • V is partitioned into two types: • P = {P1, P2, …, Pn}, the set consisting of all the processes in the system. • R = {R1, R2, …, Rm}, the set consisting of all resource types in the system. • request edge – directed edge P1  Rj • assignment edge – directed edge Rj Pi

15. Resource-Allocation Graph (Cont.) • Process • Resource Type with 4 instances • Pirequests instance of Rj • Pi is holding an instance of Rj Pi Rj Pi Rj

16. Example of a Resource Allocation Graph

17. Resource Allocation Graph With A Deadlock

18. Graph With A Cycle But No Deadlock

19. Basic Facts • If graph contains no cycles  no deadlock. • If graph contains a cycle  • if only one instance per resource type, then deadlock. • if several instances per resource type, possibility of deadlock.

20. Methods for Handling Deadlocks • Ensure that the system will never enter a deadlock state • Deadlock prevention and deadlock avoidance • Allow the system to enter a deadlock state and then recover • Deadlock detection and recovery • Ignore the problem and pretend that deadlocks never occur in the system; used by most operating systems, including UNIX • Some call it the “Ostrich” approach - why?

21. Plan for remaining classes • Penultimate class • A little history of operating systems • Significant events, important contributions, standards • What is happening now and what is likely to happen in the future • What is hot and what is not • Where could you (as a student) go from here? • Related fields • Last class • Revision of entire course • Tips for final • Both classes • Questions about the course • Feedback!

22. Deadlock Prevention Restrain the ways request can be made. • Mutual Exclusion – not required for sharable resources; must hold for nonsharable resources. • Hold and Wait – must guarantee that whenever a process requests a resource, it does not hold any other resources. • Require process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none. • Low resource utilization; starvation possible.

23. Deadlock Prevention (Cont.) • No Preemption – • If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released. • Preempted resources are added to the list of resources for which the process is waiting. • Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting. • Circular Wait – impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration.

24. Deadlock Avoidance Requires that the system has some additional a priori information available. • Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need. • The deadlock-avoidance algorithm dynamically examines the resource-allocation state to ensure that there can never be a circular-wait condition. • Resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes.

25. Avoidance algorithms • Single instance of a resource type. Use a resource-allocation graph • Multiple instances of a resource type. Use the banker’s algorithm

26. Resource-Allocation Graph Scheme • Claim edgePi  Rj indicates that process Pi may request resource Rj; represented by a dashed line. • Claim edge converts to request edge when a process requests a resource. • Request edge converted to an assignment edge when the resource is allocated to the process. • When a resource is released by a process, assignment edge reconverts to a claim edge. • Resources must be claimed a priori in the system.

27. Resource-Allocation Graph

28. Unsafe State In Resource-Allocation Graph

29. Resource-Allocation Graph Algorithm • Suppose that process Pi requests a resource Rj • The request can be granted only if converting the request edge to an assignment edge does not result in the formation of a cycle in the resource allocation graph

30. Deadlock Detection • Allow system to enter deadlock state • Detection algorithm • Recovery scheme • Terminate (deadlocked) process(es) • Preempt resources