Concurrency and OS recap. Based on Operating System Concepts with Java, Sixth Edition, 2003, Avi Silberschatz, Peter Galvin e Greg Gagne

Transcription

1 Concurrency and OS recap Based on Operating System Concepts with Java, Sixth Edition, 2003, Avi Silberschatz, Peter Galvin e Greg Gagne 64

2 Process Concept An operating system executes a variety of programs: Batch system jobs Time-shared systems user programs or tasks Textbook uses the terms job and process almost interchangeably Process a program in execution; process execution must progress in sequential fashion A process includes: program counter stack data section Operating System Concepts with Java 4. Silberschatz, Galvin and Gagne

3 Diagram of Process State Operating System Concepts with Java 4. Silberschatz, Galvin and Gagne

4 Representation of Process Scheduling Operating System Concepts with Java 4. Silberschatz, Galvin and Gagne

5 Addition of Medium Term Scheduling Operating System Concepts with Java 4. Silberschatz, Galvin and Gagne

6 Context Switch When CPU switches to another process, the system must save the state of the old process and load the saved state for the new process Context-switch time is overhead; the system does no useful work while switching Time dependent on hardware support Operating System Concepts with Java 4. Silberschatz, Galvin and Gagne

7 Interprocess Communication (IPC) Mechanism for processes to communicate and to synchronize their actions Message system processes communicate with each other without resorting to shared variables IPC facility provides two operations: send(message) message size fixed or variable receive(message) If P and Q wish to communicate, they need to: establish a communication link between them exchange messages via send/receive Implementation of communication link physical (e.g., shared memory, hardware bus) logical (e.g., logical properties) Operating System Concepts with Java 4. Silberschatz, Galvin and Gagne

8 Single and Multithreaded Processes Operating System Concepts with Java 5. Silberschatz, Galvin and Gagne

9 Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes Operating System Concepts with Java 7a. Silberschatz, Galvin and Gagne

10 Race Condition count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count-- could be implemented as register2 = count register2 = register2-1 count = register2 Consider this execution interleaving: S0: producer execute register1 = count {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2-1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4} Operating System Concepts with Java 7a. Silberschatz, Galvin and Gagne

11 Solution to Critical-Section Problem 1. Mutual Exclusion - If process P i is executing in its critical section, then no other processes can be executing in their critical sections 2. Progress - If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the processes that will enter the critical section next cannot be postponed indefinitely 3. Bounded Waiting - A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted Assume that each process executes at a nonzero speed No assumption concerning relative speed of the N processes Operating System Concepts with Java 7a. Silberschatz, Galvin and Gagne

12 Semaphore Synchronization tool that does not require busy waiting (spin lock) Semaphore S integer variable Two standard operations modify S: acquire() and release() Originally called P() and V() Less complicated Can only be accessed via two indivisible (atomic) operations acquire(s) { while S <= 0 ; // no-op } S--; release(s) { } S++; Operating System Concepts with Java 7a. Silberschatz, Galvin and Gagne

13 Deadlock and Starvation Deadlock two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes Let S and Q be two semaphores initialized to 1 P 0 P 1 acquire(s); acquire(q); acquire(q); acquire(s); release(s); release(q); release(q); release(s); Starvation indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended. Operating System Concepts with Java 7a. Silberschatz, Galvin and Gagne

14 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 tape drives. P 1 and P 2 each hold one tape drive and each needs another one. Example semaphores A and B, initialized to 1 P 0 P 1 wait (A); wait(b) wait (B); wait(a) Operating System Concepts with Java 8. Silberschatz, Galvin and Gagne

15 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. Operating System Concepts with Java 8. Silberschatz, Galvin and Gagne

16 System Model Resource types R 1, R 2,..., R m CPU cycles, memory space, I/O devices Each resource type R i has W i instances. Each process utilizes a resource as follows: request use release Operating System Concepts with Java 8. Silberschatz, Galvin and Gagne

17 Deadlock Characterization Deadlock can arise if four conditions hold simultaneously. Mutual exclusion: only one process at a time can use a resource. Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes. 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 {P 0, P 1,, P 0 } of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2,, P n 1 is waiting for a resource that is held by P n, and P 0 is waiting for a resource that is held by P 0. Operating System Concepts with Java 8. Silberschatz, Galvin and Gagne

18 Methods for Handling Deadlocks Ensure that the system will never enter a deadlock state. Allow the system to enter a deadlock state and then recover. Ignore the problem and pretend that deadlocks never occur in the system; used by most operating systems, including UNIX. Operating System Concepts with Java 8. Silberschatz, Galvin and Gagne

19 Dining-Philosophers Problem Shared data Semaphore chopstick[] = new Semaphore[5]; Operating System Concepts with Java 7a. Silberschatz, Galvin and Gagne

20 Monitor with condition variables Operating System Concepts with Java 7a. Silberschatz, Galvin and Gagne

21 CPU Scheduler Selects from among the processes in memory that are ready to execute, and allocates the CPU to one of them CPU scheduling decisions may take place when a process: 1. Switches from running to waiting state 2. Switches from running to ready state 3. Switches from waiting to ready 4. Terminates Scheduling under 1 and 4 is nonpreemptive All other scheduling is preemptive Operating System Concepts with Java 6. Silberschatz, Galvin and Gagne

22 Scheduling Criteria CPU utilization keep the CPU as busy as possible Throughput # of processes that complete their execution per time unit Turnaround time amount of time to execute a particular process Waiting time amount of time a process has been waiting in the ready queue Response time amount of time it takes from when a request was submitted until the first response is produced, not output (for time-sharing environment) Operating System Concepts with Java 6. Silberschatz, Galvin and Gagne

23 Round Robin (RR) Each process gets a small unit of CPU time (time quantum), usually milliseconds. After this time has elapsed, the process is preempted and added to the end of the ready queue. If there are n processes in the ready queue and the time quantum is q, then each process gets 1/n of the CPU time in chunks of at most q time units at once. No process waits more than (n-1)q time units. Performance q large FIFO q small q must be large with respect to context switch, otherwise overhead is too high Operating System Concepts with Java 6. Silberschatz, Galvin and Gagne

24 Real-Time Scheduling Hard real-time systems required to complete a critical task within a guaranteed amount of time Soft real-time computing requires that critical processes receive priority over less fortunate ones Operating System Concepts with Java 6. Silberschatz, Galvin and Gagne

25 Dispatch Latency Operating System Concepts with Java 6. Silberschatz, Galvin and Gagne

26 Foundations of Distributed Computing Marco Aiello Distributed Systems a.y. 2007/08 Rijksuniversiteit Groningen 89

27 Two generals problem Two Generals need to coordinate an attack against an enemy. If they attack individually, they will loose, if they attack together they will win. But the enemy lies in the middle and can intercept the coordination messages and avoid delivery Can the generals defeat the enemy? 90

28 Two generals Theorem: there is no non-trivial protocol that guarantees that the generals will always attack simultaneously Proof: Ab absurdum, suppose there is one such protocol that does the job in the minimum number of steps n>0. Consider the last message sent, the n-th. The state of the sender cannot depend on its receipt, the state of the receiver cannot depend on its arrival, so they both do not need the n-th message. So we would have a protocol with n-1 messages. But that contradict the hypothesis Fact: A solution requires reliable message delivery. 91

29 Basic definitions A distributed system is a collection of n processes p i processes (p i,p j ) and network links among Each process p i is modeled as a possibly infinite state machine with state set Q i A configuration is a vector where is the state of An event is a transition in the state machine of the process i. We distinguish two types of events: computation events and message passing events. The latter are divided into and events. An execution segment sequence C =(q 0,...,q n 1 ) q i p i φ i send(i, j, m) receive(i, j, m) α C 0 φ 1 C 1 φ 2 C 2 φ 3... of an asynchronous message-passing system is a 92

30 Complexity measures An execution is admissible if each process has an infinite number of events, and every sent message is eventually delivered (in case of synchronous system, one may omit the eventually delivered.) A system is terminated if all of its processes are in final states of their respective state machines and there are no messages in transit. The message complexity of an algorithm is the maximum, over all admissible executions of the algorithm, of the total number of messages sent. The time complexity of an (asynchronous) algorithm is the maximum number of rounds in any (timed) admissible execution of the algorithm until termination. Informally, a timed execution is one for which the longest time for a message delivery experienced in the system is taken as upper bound 93

31 Logical time Causality, clocks and other ways to miss appointments 94

32 95

33 Happened before relation φ i φ j φ i φ j event i happened before event j if i. the two events occurred at the same process and i>j φ i ii. is the event sending the uniquely identified message <M> and is the event receiving the very same message <M> φ j iii.(transitivity) There exists a sequence of events such that φ i+1 φ i+2...φ i+k with k 0, φ i φ i+1 φ i+2...φ i+k φ j the relation is a irreflexive partial order 96

34 Space-time diagrams A space-time diagram is a graphical representation of the evolution of events occurring at processes a,b,c,d,e,f are events. What is the happened before relation among all of them? 97 97

35 Logical time and logical clocks (Lamport 1978) A logical clock is a monotonically increasing software counter. It need not relate to a physical clock. Each process p i has a logical clock, LT i which can be used to apply logical timestamps to events In the initial configuration, all logical clocks are set to 0 With every message sent by process i the logical clock of i is piggybacked with the message Any internal or send event at process i, will increase by one the logical clock LT i Upon receiving a message from process j, process i will set its logical clock to max(lt i, LT j )

36 Logical time and logical clocks (Lamport 1978) What is the logical clock at all the described events? a b c d e f

37 Facts Theorem: Given and execution and two events φ i φ j in the execution, then φ i φ j, then LT (φ i ) < LT (φ j ) Question: is the converse true? The problem is that < is total order over the integers while happened before is a partial order 100

38 Vector clocks A vector clock is a vector of the size of the system, whose values monotonically increasing. VC i [j] are In the initial configuration, all entries of all vector clocks are set to 0 With every message sent by process i the vector clock of i is piggybacked with the message Any internal or send event at process i, will result in VC i [i] =VC i [i]+1 Upon receiving a message from process j, process i update its vector clock in the following way k i V C i [k] =max(vc i [k], V C j [k]) VC i [i] =VC i [i]

39 Vector clocks What is the vector clock at all the described events? What are parallel events? a b c d e f <1,0,0> <2,0,0> <2,1,0> <2,2,0> <0,0,1> <2,2,2>

40 Facts Proposition For any j in every reachable configuration VC j [i] VC i [i] φ i φ j VC(φ i ), V C(φ j ) Two events are parallel if are incomparable Theorem φ i φ j VC(φ i ) < V C(φ j ) Theorem If VC is a function that maps each event in an execution to a vector in a field in a manner that captures concurrency, then the size of the vector is at least as big as the size of the system to which the execution refers to. 103

41 Consistent Cuts A cut through an execution is a vector k number all events at all process consecutively). <k o,...k n > of positive integers (just A cut k is consistent if, for all i and j, the k i +1th computation event of i does not happen before k j th computation event in j. (I.e., the event does not depend on any other event happening after the cut.) φ j k φ i φ j φ j k <1,3> <2,4> <2,6> 104

42 Facts Fact Given a cut, there is a unique maximal consistent cut. A distributed snapshot is a cut computed by the processes. How to compute a snapshot? Assumptions: FIFO channels and each message timestamped 105

43 Distributed Snapshot (Chandy & Lamport, 1985) i. process i selects a time for the snapshot t ii.process i broadcasts the take a snapshot to all processes iii.when process j receives a snapshot request for the first time from h a.record local state b.send take a snapshot to all neighboring processes c.record messages from all channels iv.when process j receives a second snapshot request i. stop recording from the channel v. when process j has stop recording on all channels, then it sends its recoding to the initiating process i Theorem The algorithm delivers a consistent cut of the distributed system subsequent to t. 106

44 Leader Election Democracy... at last 107

45 Basic definitions Every process terminates in one of two final states: elected or non elected In every admissible execution, one and only one process will be in the elected state and all others in the non elected one Assumption: the topology is a directed ring A ring is anonymous if the processes do not have a unique identifier associated with them An algorithm is uniform if the number of nodes in the ring is not known to the processes 108

46 Bad news... Theorem There is no anonymous leader election algorithm A for asynchronous ring systems. (even a version of the theorem with stronger assumptions is valid) Theorem There is no anonymous leader election algorithm A for nonuniform synchronous ring systems. (proof ab absurdum) Lemma For every round k of the admissible execution of A in the ring R, the states of all processes at the end of round k are the same. (proof by induction) Therefore if one state machine is in the elected state, so are all the others. The second theorem implies the first one 109

47 Fault Tolerant Consensus it is all about agreement 110

48 Consensus The consensus problem is a coordination problem where a number of processes have to agree on a common output Let s consider the synchronous case with possible crashes or byzantine failures, then we consider the asynchronous case A system that can tolerate up to f crashes is called f-resilient We identify a subset F of the processes of the system as faulty processes Each round contains exactly one computation for all processes not in F and at most one for the ones in F 111

49 Consensus in Synchronous Systems with Crashes Each process p i has an input variable x i and an output variable y i (also called decision) Initially, x i can be any value in a given domain and y i is undefined. Assignment of is irreversible and thus final. y i A solution to the consensus problem must guarantee the following in every admissible execution: Termination Agreement Validity p i F : y i p i,p j F : y i y j then y i = y j p i x i = v p j Fy j : y j = v 112

50 A simple algorithm Initially V = {x} round k, 1 k f+1 send to all processes receive Sj from pj, 0 j n-1 and j different from i V := V n 1 j=0 S j if k = f+1 then y := min(v) {v V : p i has not already sent v} 113

51 Simple algorithm and beyond Lemma In every execution at the end of round f + 1, Vi = Vj, for every two nonfaulty processes pi and pj. Theorem The algorithm solves the consensus problem in the presence of f crash failures within f + 1 rounds. Theorem Any consensus algorithm for n processes that is resilient to f crashes requires at least f + 1 rounds in some admissible execution, for all n f

52 The Byzantine case Byzantine army is attacking a city and they can use reliable messengers. They need to decide whether to attack or not (agreement). If they are unanimous in the attack decision, then they should attack (validity). But some of the generals could be Byzantine traitors and send malicious, conflicting messages or even form a coalition. Theorem In a systems with three processes and one Byzantine process, there is no algorithm that solves the consensus problem. Theorem (lower bound on number of faulty processes) In a system with n processes and f Byzantine processes, there is no algorithm that solves the consensus problem if n 3 f. 115

53 The Byzantine case Theorem There exists an algorithm for n processes that solves the consensus problem in the presence of f Byzantine failures within f + 1 rounds using exponential size messages, if n > 3 f. Theorem There exists an algorithm for n processes that solves the consensus problem in the presence of f Byzantine failures within 2 (f + 1) rounds using constant size messages, if n > 4 f. 116

54 The asynchronous case Theorem There is no wait-free algorithm for solving the consensus problem in an asynchronous shared memory system with n processes and the possibility of crashes. Theorem There is no algorithm for solving the consensus problem in an asynchronous message-passing system with n processes, of which any may fail by crashing. 117

55 References Hagit Attiya and Jennifer Welch Distributed Computing: Fundamentals, Simulations and Advanced Topics, Wiley, Lorenzo Alvisi s course on Distributed Computing at Univ. of Texas (Google it) 118