1 / 67

Concurrency: Mutual Exclusion and Synchronization

Concurrency: Mutual Exclusion and Synchronization. Chapter 5. Concurrency. Arises due to the loading of multiple processes in memory at the same time (multiprogramming) Uniprocessor system: interleave execution of processes Multiprocessor system: interleave & overlap execution of processes

Anita
Download Presentation

Concurrency: Mutual Exclusion and Synchronization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Concurrency: Mutual Exclusion and Synchronization Chapter 5

  2. Concurrency • Arises due to the loading of multiple processes in memory at the same time (multiprogramming) • Uniprocessor system: interleave execution of processes • Multiprocessor system: interleave & overlap execution of processes • Interleaving and overlapping present the same fundamental problems

  3. Problems with concurrency • Concurrent processes (or threads) often need to share global data and resources • If there is no controlled access to shared data, some processes will obtain an inconsistent view of this data • The action performed by concurrent processes will then depend on the order in which their execution is interleaved

  4. An example static char a; void echo() { cin >> a; cout << a; } • Process P1 and P2 are running this same procedure and have access to the same variable “a” • Processes can be interrupted anywhere • If P1 is first interrupted after user input and P2 executes entirely • Then the character echoed by P1 will be the one read by P2 !!

  5. Process Interaction • Processes unaware of each other- multiple independent processes- competition for resources • Processes indirectly aware of each other- do not know each other’s process ID- cooperation by sharing some object • Processes directly aware of each other- know each other’s process ID- cooperation by communication

  6. Competition Among Processes for Resources • If two or more processes wish access to a single resource, one process will be allocated the resource and the others will have to wait • Control problems:- mutual exclusion- deadlock- starvation

  7. Critical Section • Critical resource: only one process must be allowed access at a time (mutual exclusion) • Critical section: portion of program that uses the critical resource- enforce mutual exclusion on critical section

  8. Cooperation Among Processes by Sharing • Processes use and update shared data such as shared variables, files, and databases • Cooperate to ensure data integrity • Control problems: mutual exclusion, deadlock, starvation • Only write operations must be mutually exclusive • New problem: data coherence

  9. Data Coherence Example • Items a and b must satisfy a = b • Process P1:a = a + 1;b = b + 1; • Process P2:a = 2 * a;b = 2 * b; • Problem sequence of execution (a = b = 2):a = a + 1; => a = 3 a = 2 * a; => a = 6b = 2 * b; => b = 4b = b + 1; => b = 5

  10. Cooperation Among Processes by Communication • Communication provides a way to synchronize, or coordinate, the various activities • Nothing shared: Mutual exclusion not a requirement • Possible to have deadlock • each process waiting for a message from the other process • Possible to have starvation • two processes sending message to each other while another process waits for a message

  11. Requirements for Mutual Exclusion, I. • Only one process at a time is allowed in the critical section for a resource • If a process halts in its noncritical section, it must not interfere with other processes • A process requiring the critical section must not be delayed indefinitely: no deadlock or starvation

  12. Requirements for Mutual Exclusion, II. • A process must not be delayed access to a critical section when there is no other process using it • No assumptions are made about relative process speeds or number of processes • A process remains inside its critical section for a finite time only

  13. The critical section problem, I. • When a process executes code that manipulates shared data (or resource), we say that the process is in it’s critical section (CS) (for that shared data) • The execution of critical sections must be mutually exclusive: at any time, only one process is allowed to execute in its critical section (even with multiple processors) • Then each process must request the permission to enter its critical section (CS)

  14. The critical section problem, II. • The section of code implementing this request is called the entry section • The critical section (CS) might be followed by an exit section • The remaining code is the remainder section (RS) • The critical section problem is to design a protocol that the processes can use so that the requirements of mutual exclusion can be met

  15. Each process executes at nonzero speed but no assumption on the relative speed of n processes General structure of a process: many processors may be present but memory hardware prevents simultaneous access to the same memory location No assumption about order of interleaved execution For solutions: we need to specify entry and exit sections Framework for analysis of solutions repeat entry section critical section exit section remainder section forever

  16. Types of solutions • Software solutions • algorithms who’s correctness does not rely on any other assumptions (see framework) • Hardware solutions • rely on some special machine instructions • Operation System solutions • provide some functions and data structures to the programmer

  17. Types of Solutions • Note: Solutions presented assume • Single processor system or • Multiprocessor system with shared main memory. • Later in Chapter 5, we will examine Message Passing. This technique lends itself best to • Distributed Systems (Clusters).

  18. Software solutions • We consider first the case of 2 processes • Algorithm 1 and 2 are incorrect • Algorithm 3 is correct (Peterson’s algorithm) • Notation • We start with 2 processes: P0 and P1 • Pi and Pj refer to different processes (i not equal to j)

  19. The shared variable turn is initialized (to 0 or 1) before executing any Pi Pi’s critical section is executed iff turn = i Pi is busy waiting if Pj is in CS: mutual exclusion is satisfied Drawbacks:- processes must strictly alternate in the use of CS- If Pi fails Pj is blocked forever Algorithm 1 Process P0: repeat while(turn!=0){}; CS turn:=1; forever Process P1: repeat while(turn!=1){}; CS turn:=0; forever

  20. Use one Bool variable for each process: flag[0] and flag[1] Pi signals that it is ready to enter it’s CS by: flag[i]:=true Mutual Exclusion is satisfied but could lead to deadlock If we have the sequence: T0: flag[0]:=true T1: flag[1]:=true Both process will wait forever to enter their CS: we have a deadlock Algorithm 2 Process P0: repeat flag[0]:=true; while(flag[1]){}; CS flag[0]:=false; forever Process P1: repeat flag[1]:=true; while(flag[0]){}; CS flag[1]:=false; forever

  21. Initialization: flag[0]:=flag[1]:=false turn:= 0 or 1 Ready to enter CS specified by flag[i]:=true If both processes attempt to enter their CS simultaneously, only one turn value will last Exit section: specifies that Pi is not ready to enter CS Algorithm 3 (Peterson’s algorithm) Process P0: repeat flag[0]:=true; turn:=1; while (flag[1]and turn=1){}; CS flag[0]:=false; forever Process P1: repeat flag[1]:=true; turn:=0; while (flag[0]and turn=0){}; CS flag[1]:=false; forever

  22. Algorithm 3: proof of correctness • Mutual exclusion is preserved: • P0 and P1 are both in CS only if flag[0] = flag[1] = true and only if turn = i for each Pi (impossible) • No mutual blocking: • Assume P0 is blocked in its while loop (flag[1]=true and turn=1). It can enter its CS when either flag[1] = false or turn = 0. Three exhaustive cases:1. P1 has no interest in its CS: Impossible because it implies flag[1] = false. 2. P1 is waiting for its CS: Impossible because if turn = 1, P1 can enter its CS.3. P1 is monopolizing access to CS: Cannot happen because P1 sets turn=0 before each attempt to enter its CS.

  23. Drawbacks of software solutions • Processes that are requesting to enter in their critical section are busy waiting (consuming processor time needlessly) • If CSs are long, it would be more efficient to block processes that are waiting...

  24. On a uniprocessor:no overlapping of execution Therefore, if a process doesn’t get interrupted in its CS, mutual exclusion can be guaranteed. Hardware solutions: interrupt disabling Process Pi: repeat disable interrupts critical section enable interrupts remainder section forever • Degrades efficiency because processor cannot interleave programs when interrupts are disabled • On a multiprocessor: mutual exclusion is not preserved • Generally not an acceptablesolution

  25. Hardware solutions: special machine instructions • Normally, memory hardware ensures access to a memory location is mutually exclusive • Extension: machine instructions that perform two actions atomically (indivisible) on the same memory location (eg: reading and testing) • Not subject to interference from other instructions because actions performed in single instruction cycle (even with multiple processors)

  26. A C++ description of test-and-set: An algorithm that uses testset for Mutual Exclusion: Shared variable b is initialized to 0 Only the first Pi who sets b enter CS The test-and-set instruction bool testset(int &i) { if (i==0) { i=1; return true; } else { return false; } } Process Pi: repeat repeat{} until testset(b); CS b:=0; RS forever

  27. The test-and-set instruction (cont.) • Mutual exclusion is preserved: if Pi enter CS, the other Pj are busy waiting • Problem: still using busy waiting • Processors (ex: Pentium) often provide an atomic xchg(a,b) instruction that swaps the contents of a and b (register and memory). • But xchg(a,b) suffers from the same drawbacks as test-and-set

  28. Shared variable b is initialized to 0 Each Pi has a local variable k The only Pi that can enter CS is the one that finds b=0 This Pi excludes all the other Pj by setting b to 1 Sets b back to 0 on leaving CS Using xchg for mutual exclusion Process Pi: repeat k:=1 repeat xchg(k,b) until k=0; CS b:=0; RS forever

  29. Properties of machine instructions • Advantages: • Applicable to any number of processes • Can be used on single as well as multiple processor machines sharing main memory • Simple and easy to verify

  30. Properties … (cont’d) • Disadvantages: • Busy waiting consumes processor time • Starvation is possible: selection of waiting process is arbitrary; some process could be denied access indefinitely. • Deadlock is possible: P1 is interrupted in CS. P2 of higher priority tries to use same resource and goes into busy waiting. P1 is not dispatched because it is of lower priority.

  31. Semaphores, I. • Synchronization tool (provided by the OS) that do not require busy waiting • Processes cooperate by means of signals; a process can be made to wait on a signal • A semaphore S is an integer variable with the following operations defined on it • Initialization to non-negative value (1 for mutual exclusion) • wait(S): decrements value, blocks process if value becomes negative • signal(S): increments value, unblocks one process if value is not positive.

  32. Semaphores • Note: semaphores can be used for • Synchronization • Mutual exclusion • Two separate, but similar problems • Descriptions presented are general • Notes are added for mutual exclusion to disallow semaphore.count > 1

  33. Hence, in fact, a semaphore is a record (structure): When a process must wait for a semaphore S, it is blocked and put on the semaphore’s queue The signal operation removes (according to a fair policy like FIFO) one process from the queue and puts it in the list of ready processes Semaphores, II. type semaphore = record count: integer; queue: list of process end; var S: semaphore;

  34. Semaphore’s operations (atomic) wait(S): S.count--; if (S.count<0) { block this process place this process in S.queue } signal(S): S.count++; if (S.count<=0) { remove a process P from S.queue place this process P on ready list } S.count must be initialized to a nonnegative value (1 for mutual exclusion)

  35. Semaphores: observations, I. • When S.count >=0: the number of processes that can execute wait(S) without being blocked = S.count (! > 1 for mutual exclusion) • When S.count<0: the number of processes waiting on S is = |S.count| • Atomicity and mutual exclusion: no 2 process can be in wait(S) or signal(S) (on the same S) at the same time (even with multiple CPUs) • Hence the blocks of code defining wait(S) and signal(S) are, in fact, critical sections

  36. Semaphores: observations, II. • The critical sections defined by wait(S) and signal(S) are very short: typically 10 instructions • Solutions: • uniprocessor: disable interrupts during these operations (ie: for a very short period). This does not work on a multiprocessor machine. • multiprocessor: use previous software or hardware schemes. The amount of busy waiting should be small.

  37. Using semaphores for solving critical section problems • For n processes • Initialize S.count to 1 • Then only 1 process is allowed into CS (mutual exclusion) • To allow k processes into CS, we initialize S.count to k (! mut. ex.) • When CS is exited, S.count is incremented and one of the blocked processes is moved to the Ready state Process Pi: repeat wait(S); CS signal(S); RS forever

  38. We have 2 processes: P1 and P2 Statement S1 in P1 needs to be performed before statement S2 in P2 Then define a semaphore “synch” Initialize synch to 0 Proper synchronization is achieved by having in P1: S1; signal(synch); And having in P2: wait(synch); S2; Using semaphores to synchronize processes

  39. Binary semaphores • The semaphores we have studied are called counting (or integer) semaphores • We have also binary semaphores • similar to counting semaphores except that “count” is Boolean valued (0 or 1) • counting semaphores can be implemented by binary semaphores... • generally more difficult to use than counting semaphores (eg: they cannot be initialized to an integer k > 1)

  40. Binary semaphores waitB(S): if (S.value = 1) { S.value := 0; } else { block this process place this process in S.queue } signalB(S): if (S.queue is empty) { S.value := 1; } else { remove a process P from S.queue place this process P on ready list }

  41. Spinlocks • They are counting semaphores that use busy waiting (instead of blocking) • Useful on multi processors when critical sections last for a short time • We then waste a bit of CPU time but we save process switch wait(S): S--; while S<0 do{}; signal(S): S++;

  42. Problems with semaphores • Semaphores provide a powerful tool for enforcing mutual exclusion and coordinating processes • But wait(S) and signal(S) are scattered among several processes. Hence, difficult to understand their effects • Usage must be correct in all the processes • One bad (or malicious) process can fail the entire collection of processes

  43. The producer/consumer problem • A producer process produces data items that are consumed by a consumer process • Eg: a print program produces characters that are consumed by a printer • We need a buffer to hold items that are produced and eventually consumed • A common paradigm for cooperating processes

  44. P/C: unbounded buffer • We assume first an unbounded buffer consisting of a linear array of elements • in points to the next item to be produced • out points to the next item to be consumed

  45. P/C: unbounded buffer • We need a semaphore S to perform mutual exclusion on the buffer: only 1 process at a time can access the buffer • We need another semaphore N to synchronize producer and consumer on the number N (= in - out) of items in the buffer • an item can be consumed only after it has been created

  46. P/C: unbounded buffer • The producer is free to add an item into the buffer at any time: it performs wait(S) before appending and signal(S) afterwards to enforce mutual exclusion • The producer also performs signal(N) after each append to increment N • The consumer must first do wait(N) to see if there is an item to consume and use wait(S)/signal(S) to access the buffer

  47. Solution of P/C: unbounded buffer Initialization: S.count:=1; N.count:=0; in:=out:=0; append(v): b[in]:=v; in++; Producer: repeat produce v; wait(S); append(v); signal(S); signal(N); forever Consumer: repeat wait(N); wait(S); w:=take(); signal(S); consume(w); forever take(): w:=b[out]; out++; return w; critical sections

  48. P/C: unbounded buffer • Remarks: • Putting signal(N) inside the CS of the producer (instead of outside) has no effect since the consumer must always wait for both semaphores before proceeding • The consumer must perform wait(N) before wait(S), otherwise deadlock occurs if consumer executes wait(N) while the buffer is empty • Could be difficult to produce correct designs using semaphores

  49. P/C: finite circular buffer of size k • can consume only when number N of (consumable) items is at least 1 (now: N!=in-out) • can produce only when number E of empty spaces is at least 1

  50. P/C: finite circular buffer of size k • As before: • we need a semaphore S to have mutual exclusion on buffer access • we need a semaphore N to synchronize producer and consumer on the number of consumable items • In addition: • we need a semaphore E to synchronize producer and consumer on the number of empty spaces

More Related