Course Overview Principles of Operating Systems

1. Introduction Computer System Structures Operating System Structures Processes Process Synchronization Deadlocks CPU Scheduling Memory Management Virtual Memory File Management Security Networking Distributed Systems Case Studies Conclusions Course OverviewPrinciples of Operating Systems

2. Motivation Objectives Concurrency Synchronization Problems Race Conditions Critical Sections Mutual Exclusion Synchronization Methods Hardware Semaphores Monitors Synchronization Patterns Bounded Buffer Readers-Writers Dining Philosophers Important Concepts and Terms Chapter Summary Chapter Overview Process Synchronization

3. Motivation • several processes exist simultaneously in a system • co-existing processes may interfere with each other’s execution • incorrect calculations,decrease in efficiency,deadlock • processes may cooperate within the same task • the activities of cooperating processes need to be coordinated • the use of shared resources must be coordinated • the separation of independent activities in processes may lead to higher performance and more convenient use

4. Objectives • recognize potential problems with the coordination of activities for several processes (cooperation or resource sharing) • know how to use synchronization methods to prevent problems • be aware of the advantages and problems of different synchronization methods • be familiar with some fundamental synchronization patterns

5. Process Synchronization • the activities of several concurrent processes are synchronized • access to common resources is coordinated

6. Importance of Synchronization • prevention and elimination of race conditions, deadlocks and starvation • serious ramifications can occur otherwise (Therac 25) • data integrity/consistency • collaboration • efficiency [Son 97] [2] “An Investigation of the Therac-25 Accidents” 2

7. Concurrency • several processes are active at the same time • between their start and finish operations • each process must make some progress • multitasking, multiprogramming • process multiplexing: the CPU switches between different processes • to the human user, these processes seem to be executed simultaneously • multiprocessing • several processes are executed simultaneously by multiple processing elements (CPUs)

8. Resource Types • shared: several processes can utilize them simultaneously • exclusive: only one process at a time • preemptible: can be taken away from a process, given to another, and returned to the old process • non-preemptible: one process must finish before another can use the resource

9. Synchronization Problems • race conditions • the exact timing in the execution of concurrent processes is critical • critical sections • part of a program that must be protected from interference • usually resolved via mutual exclusion • mutual exclusion • the usage of resources by processes is restricted • usually: only one process may use one instance of a resource

10. Race Conditions • the final result of an activity involving shared resources depends on the timing of processes • caused by • the division of activities into several separate operations (multitasking on a single CPU) • simultaneous operations on shared resources in multiprocessor systems • race conditions may happen only very rarely • coincidence of the interruption of an operation and manipulation of shared resources by another process • very difficult to detect and reproduce

11. Example Race Conditions • procedure for a character echo function procedure echo; var out, in: character; begin input (in, keyboard); out := in; output (out, display) end. [Stallings 98]

12. Example Race Conditions • two processes A and B use the echoprocedure • implicitly shared variables out, in • no restrictions on modifications of the variables Process A . input (in, keyboard) . out := in; output (out, display) . . Process A . input (in, keyboard) out := in; . output (out, display) . [Stallings 98]

13. Example Race Conditions • problem • the value of the shared variable in depends on the exact timing between the two processes • undesired results (the same value is echoed by both processes) • solution • control access to shared resources • here: protect shared variables by allowing only one process at a time in the procedure echo • echo is an example for a critical section

14. Handling of Race Conditions • guarantee the correct sequence of execution through process synchronization mechanisms • relies on the correct use of these mechanisms by the processes • delay the execution of one process • improper, but frequently used “hack”, often depending on hardware specifics like processor speed

15. Critical Sections • several processes cooperate on a task by sharing resources • a critical section is a segment of code in which a process utilizes some shared resources, and no other process may interfere • execution of critical sections must be mutually exclusive in time • there may be different critical sections for different sets of shared resources • a protocol us required to guarantee that only one process is in the critical section

16. entry section critical section Critical Section Diagram repeat other code exit section other code until false;

17. Critical Section Requirements • solutions for the critical section problem must satisfy • mutual exclusion • if one process is executing in its critical section, then no other processes can execute in their critical sections • progress • processes wishing to enter their critical sections must come to a decision eventually • bounded waiting • after a process has made a request to enter its critical section, only a finite number of other processes may go first • assumptions • processes execute at non-zero speed • no assumptions on their relative speed

18. Two-Process Solutions • critical section problem with only two processes • shared Boolean or integer variables for synchronization • Algorithm 1 • turn variable to switch between the two processes • Algorithm 2 • flag variable for each process to indicate that it wants to enter its critical section • Algorithm 3 • combination of the above two

19. Algorithm 1 • processes P0 and P1 share a common variable turn initialized to 0 or 1. • if turn = 0 then process P0 enters critical section • if turn = 1 then process P1 enters critical section

20. while turn <> i do no-op; critical section turn := j; Diagram of Algorithm 1 repeat other code other code until false;

21. Evaluation Algorithm 1 • Requirements satisfied? • mutual exclusion • yes, only one process is allowed in its critical section • progress • no, requires strict alternation • bounded waiting • yes, exactly one waiting period is required

22. Algorithm 2 • an array flag of two elementsflag[0] and flag[1] indicates if a process wants to enter its critical section • if flag[i] is true, then Pi is ready to enter its critical section • elements of the array flag are initialized to false [Son 97] [Silberschatz & Galvin, 1998] 30

23. critical section flag[i] := false; Diagram of Algorithm 2 repeat other code flag[i] := true while flag[j] do no-op; other code until false;

24. Problems with Algorithm 2 • Problem: What happens if P0 sets flag[0] to true and P1 sets flag[1] to true before they get into their while statement? • Answer: Infinite loop within whilestatements • depends too much on the exact timing of the two processes • not very likely, but may happen [Son 97] [Silberschatz & Galvin, 1998] 32

25. Evaluation Algorithm 2 • Requirements satisfied? • mutual exclusion • yes, only one process is allowed in its critical section • progress • no, endless loop in the entry sections possible if both processes set their flags simultaneously • switching the order of the two instructions in the entry section is not a solution, it will lead to mutual exclusion problems • bounded waiting • yes, a process sets flag in the exit section such that the other can continue

26. Algorithm 3 • combination of algorithms 1 & 2 • designed to meet all three mutual exclusion requirements • processes share two Boolean variables • turn • the array flag [Son 97] [Silberschatz & Galvin, 1998] 33

27. critical section flag[i] := false; Diagram of Algorithm 3 repeat other code flag[i] := true; turn := j; while (flag[j] and turn = j) do no-op; other code until false;

28. Algorithm 3 - Visualization Process i Process j flag[i]:= true turn := j flag[j]:= true turn := i the expression (flag[i] and turn = i) isfalse enters critical section flag[j] := false executing ‘no-op’ until the expression (flag[j] and turn = j) becomesfalse enters critical section flag[i] := false

29. Analysis of Algorithm 3 • a process Pi can enter its critical section only if • flag[j] = false (the other process doesn’t want to enter its critical section), or • turn = i (the other process wants to enter its critical section, but set the turn variable to process Pi ) • the two processes cannot be both in their while loops because turn can either be true or false, but not both • in its exit section, a process resets its flag variable, thus permitting the other process entry [Son 97] [Silberschatz & Galvin, 1998] 36

30. Evaluation Algorithm 3 • Requirements satisfied? • mutual exclusion • yes • progress • yes • bounded waiting • yes • algorithm 3 is a satisfactory solution for the two-process critical section problem • how can this algorithm be extended to n processes?

31. Multiple-Process Critical Section • critical section problem with n processes • one solution utilizes the “bakery algorithm” • customers pick a number when they enter the store, and are served according to the value of their numbers • each process calculates a number when it wants to enter the critical section • based on the maximum number already assigned • process with the lowest number gets served first • If two processes have the same number, then the process with the lower process id gets served first [Son 97] [Silberschatz & Galvin, 1998] 37

32. Bakery Algorithm • designed with distributed systems in mind • relies on two arrays of variables • choosing: array[0..n-1] of Boolean • indicates that a process is calculating its number • number: array[0..n-1] of integer • used as identifier for processes • under certain circumstances, two processes may have the same number (if they arrive at the same time) [Son 97] [Silberschatz & Galvin, 1998] 38

33. choosing[i] := true; number[i] := max(number[0],number[1],...,number[n-1]) + 1; choosing[i] := false; for j := 0 to n - 1 do begin while choosing[j] do no-op; while number[j] <> 0 and (number[j],j) < (number[i],i) do no-op; end; Code Bakery Algorithm repeat critical section number[i] := 0; other code until false; 40

34. Mutual Exclusion • requires that only one process performs operations on shared resources • if two processes attempt to access a shared resource simultaneously, one will have to wait • necessary for the protection of critical sections

35. Handling Mutual Exclusion • protect access to resources through synchronization mechanisms • implicit synchronization for many cases through the use of system calls • not sufficient, since many system calls are reentrant

36. Implementing Mutual Exclusion • hardware • special instructions • OS • data structures and operations provided by the OS, e.g. via system calls • programming language • constructs at the language level (e.g. rendezvous in Ada) • application • application programmer must take care of it • all solutions usually involve critical sections

37. H/W Mutual Exclusion • special machine instructions that do two steps indivisibly • test_and_set: test a value; if it is false set it to true, else leave it as false • exchange: swap the values of two variables • test_and_set • exchange while (test_and_set(lock)) do no-op; critical section lock := false; key := true repeat exchange(lock, key) until (key = false); critical section lock := false;

38. Characteristics • hardware-based mutual exclusion • advantages • can be used by a single- or multi-processor systems (with shared memory) • simple, easy to verify • supports multiple critical sections • disadvantages • often busy waiting is used • starvation is possible • deadlock is possible (especially with priorities)

39. Disabling Interrupts • interrupts are disabled during the time period when mutual exclusion is required • without interrupts no process switching can occur • somewhat dangerous: one process can hold up the whole system • endless loop • waiting for resources • used in special-purpose systems with limited hardware

40. OS Mutual Exclusion • mechanisms to handle mutual exclusion are provided by the operating system • semaphores, mutexes, monitors, rendezvous, etc. • available to user processes via system calls • provided in most modern OSs

41. Programming Language Mutual Exclusion • mutual exclusion mechanisms are built into the programming language • rendezvous in Ada, monitors in Pascal/Modula • often relies implicitly on OS mechanisms

42. Application Mutual Exclusion • implemented by the application programmer • difficult to do right • frequently practically impossible to test sufficiently • very inefficient • usually relies on busy waiting

43. Dangers of Mutual Exclusion • solutions to the mutual exclusion problem may lead to • starvation • deadlock • inefficiency

44. Starvation • indefinite postponement of a process • a process never gets a resource because the resource is allocated to other processes • higher priority • consequence of scheduling algorithm • frequent solution: aging • the longer a process waits for a resource, the higher its priority until it eventually has the highest priority among the competing processes

45. Deadlock • several processes are waiting for an event that never occurs because it only can be caused by one of the waiting processes • example: process A waits for process B, and process B waits for process A • in real life, deadlock is usually resolved by applying politeness or common sense; processes don’t have common sense, they stick to their programs

46. Student A get coursenotes get textbook study release textbook release coursenotes Student B get textbook get coursenotes study release coursenotes release textbook Example Deadlocks • studying students: both students need the textbook and the course notes to study, but there is only one copy of each • consider the following situation:

47. Synchronization Methods • hardware • semaphores • monitors

48. Hardware • based on special instructions like test_and_set, exchange • often in combination with interrupts • sometimes used as basis for OS synchronization mechanisms

49. Semaphores • used to solve synchronization problems among n processes • fundamental synchronization tool used in many operating systems • integer variable that can be accessed only via two atomic operations • wait • signal • frequently used for mutual exclusion • mutex as special semaphore [Son 97] [Silberschatz & Galvin, 1998] 2

50. Semaphore Usage - Example • goal: force P2 to execute after P1 • common semaphore synch to synchronize the operations of the two concurrent processes • wait, signal utilized to delay P2 until P1 is done • synch initialized to 0 [Son 97] [Silberschatz & Galvin, 1998] 5