1 / 140

Chapter 2

Chapter 2. Processes and Scheduling (II). Mutual Exclusion and Synchronization. Principles of concurrency. Mutual Exclusion : Software approaches and Hardware Support. Semaphores 、 Monitors 、 Message Passing. Tradition question: Producer/Consumer 、 Readers/Writers Problem.

marja
Download Presentation

Chapter 2

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. Chapter 2 Processes and Scheduling (II)

  2. Mutual Exclusion and Synchronization • Principles of concurrency. • Mutual Exclusion: Software approaches and Hardware Support. • Semaphores、Monitors、Message Passing. • Tradition question: Producer/Consumer、Readers/Writers Problem.

  3. Difficulties Arise in Concurrency • Types: interleaving and overlapping. • The sharing of global resources is fraught with peril. • It is difficult for the OS to manage the allocation of resources optimally. • It is difficult to locate a programming error, because results are typically not reproducible.

  4. Sharing can lead to problems Process P1 . input (in, keyboard) . out:=in output (out, display) . . Process P2 . input (in, keyboard) . out:=in output (out, display) . . So, it is necessary to protect shared global variables.

  5. Problems of Concurrent • Resource competition: How to allocate the resource, and how to mutual exclusion access the critical resources. • Execution sequence. • Communication cooperation.

  6. Process Interaction (table5.1) • Processes unaware of each other: OS needs to be concerned about competition for resources. Exp. Two independent applications may both want access to the same disk or file or printer. • Processes indirectly aware of each other(e.g., shared object): The processes share access to some object such as I/O buffer. • Processes directly aware of each other: Communicate with each other by name.

  7. Mutual Exclusion(P193) • Critical resource: Only one process can access it at a time. • Critical section：the portion of the program that uses critical resource. entry section critical section exit section

  8. P194，fig5.1 Program mutualexclusion Const n-…; (*num of processes) Procedure P(i:integer) Begin repeat enter critical(R) <critical section>; exit critical(R) <remainder> forever End; Begin(*main program*) parbegin p1; p2; … pn; parend End.

  9. Deadlock and Starvation(P194) • Deadlock • Exp. Two processes P1、P2, both request to resource R1、R2. At a time: • P1 gets R2 and P2 gets R1, in the meantime P1 requests R1 and P2 requests R2 • Then P1 and P2 wait for each other forever ---deadlock. • Starvation • P1 always communication with P2, p3 is starved.

  10. Cooperation among Processes by Sharing(p195) • Data integrity • Reading and writing, and only writing operations must be exclusive. • Data coherence: a=b no longer holds P1: a:=a+1 b:=b+1 P2: b:=2*b a:=2*a a:=a+1 b:=2*b b:=b+1 a:=2*a

  11. Cooperation among Processes by Communication • Synchronize: The processes send and receive data between each other coordinately.

  12. Requirements for Mutual Exclusion (互斥)(P196） • Mutual exclusion must be enforced. • A process that halts in its noncritical section must do so without interfering with other processes. • It must not be possible for a process requiring access to a critical section to be delayed indefinitely.

  13. Requirements for Mutual Exclusion • When no process is in a critical section, any process that requests entry to its critical section must be permitted to enter without delay. • No assumptions are made about relative process speeds or number of processors. • A process remains inside its critical section for a finite time only.

  14. Mutual Exclusion: Software Approaches • Dekker’s Algorithm • Peterson’s Algorithm

  15. Dekker’s Algorithm—First Attempt • Fig 5.2 An Igloo for Mutual Exclusion • The entrance and the igloo itself are small enough that only one person can be in the igloo at a time. Inside, there is a blackboard on which a single value can be written. • A process wishing to execute its critical section first enters the igloo and examines the blackboard.

  16. Dekker’s Algorithm —First Attempt • If its number is on the blackboard, then the process may leave the igloo and proceed to its critical section. After has completed the critical section, it should place the number of the other process on the board • If not its number, it leaves the igloo and is forced to wait. From time to time, the process reenters the igloo to check the blackboard until it is allowed to enter its critical section. (busy waiting)

  17. Dekker’s Algorithm —First Attempt var turn:0..1; PROCESS 1 … while turn ≠ 1 do {nothing}; <critical section> turn:=0; … PROCESS 0 … while turn≠0 do {nothing}; <critical section>; turn:=1; … • Processes must strictly alternate in their use of their critical sections.

  18. Dekker’s Algorithm –Second Attempt • Fig5.3:A two-Igloo solution for mutual exclusion (P199) • Each process may examine the other’s board but cannot alter it. • When a process wishes to enter its critical section, it periodically checks the other’s board until it finds “FALSE” written on it, indicating that the other process is not in its critical section.

  19. Dekker’s Algorithm –Second Attempt • If false, writes “true” on its own board and enter. After finish, alter its board to show “false” • If true，busy waiting

  20. Dekker’s Algorithm –Second Attempt PROCESS 1 … while flag[0] do {nothing}; flag[1]:=true; <critical section>; flag[1]:=false; … var flag : array [0..1] of boolean :false ; PROCESS 0 … while flag[1] do {nothing}; flag[0]:=true; <critical section>; flag[0]:=false; …

  21. Dekker’s Algorithm –Second Attempt • Analysis Cannot guarantee mutual exclusion: P0： flag[1]=false; do while flag[1]; P1：flag[0]=false; do while flag[0]; P0：flag[0]=true; <critical section>; P1：flag[1]=true; <critical section>;

  22. Dekker’s Algorithm –Third Attempt PROCESS 1 … flag[1]:=true; while flag[0] do {nothing}; <critical section> flag[1]:=false; … var flag : array [0..1] of boolean : false; PROCESS 0 … flag[0]:=true; while flag[1] do {nothing}; <critical section>; flag[0]:=false; …

  23. Dekker’s Algorithm –Third Attempt • Analysis P0：set flag[0]=true; P1：set flag[1]=true; P0：do: while flag[1]; block； P1：do: while flag[0]; block； =>causing deadlock

  24. Dekker’s Algorithm –Fourth Attempt PROCESS 0 … flag[0]:=true; while flag[1] do begin flag[0] :=false; <delay for a short time>; flag[0]:=true; end; <critical section>; flag[0]:=false; … PROCESS 1 … flag[1]:=true; while flag[0] do begin flag[1] :=false; <delay for a short time>; flag[1]:=true; end; <critical section> flag[1]:=false; …

  25. Dekker’s Algorithm –Fourth Attempt • Analysis P0：set flag[0]=true; P1：set flag[1]=true; P0：do, while flag[1]; P1：do,while flag[0]; P0：set flag[0]=false; P1：set flag[1]=false; P0：set flag[0]=true; P1：set flag[1]=true; …… Repeat this sequence forever, both process cannot enter the critical section. (not deadlock)

  26. Dekker’s Algorithm –A Correct Solution Procedure P0; Begin repeat flag[0]:=true; while flag[1] do if turn=1 then begin flag[0]:=false; while turn=1 do {nothing} flag[0]:=true; end <critical section>; turn:=1; flag[0]:=false; <remainder> forever End; Var flag:array[0..1] of boolean; turn:0..1; Procedure P1; Begin repeat flag[1]:=true; while flag[0] do if turn=0 then begin flag[1]:=false; while turn=0 do {nothing} flag[1]:=true; end <critical section>; turn:=0; flag[1]:=false; <remainder> forever End;

  27. Dekker’s Algorithm –A Correct Solution Begin flag[0]:=false; flag[1]:=false; turn:=1; parbegin P0; P1; parend end

  28. Dekker’s Algorithm –A Correct Solution • Analysis (P0） Set flag[0]:=true; Do, while flag[1] • false, P0 enters,when finish,set turn:=1; flag[0]:=false; • true, check value of turn • 1,busy waiting • 0, P1 has finished (but has not modified flag), P0 enters

  29. Peterson Algorithm Var flag:array[0..1] of boolean; turn: 0..1; Procedure P0; Begin repeat flag[0]:=true; turn:=1; while flag[1] and turn =1 do {nothing} <critical section> flag[0]:=false; <remainder> forever End; Procedure P1; Begin repeat flag[1]:=true; turn:=0; while flag[0] and turn =0 do {nothing} <critical section> flag[1]:=false; <remainder> forever End;

  30. Peterson Algorithm Begin flag[0]:=false; flag[1]:=false; turn:=1; parbegin P0; P1; parend End.

  31. Peterson Algorithm • Analysis • Flag is used for who wants to enter. • Turn is used to avoid deadlock.

  32. Mutual Exclusion: Hardware Support • Interrupt Disabling • Only suitable for single processor, and the efficiency of execution is degraded. • Special Machine Instructions : These actions are performed in a single instruction cycle, they are not subject to interference from other instrcutions. • Test and Set • Exchange Instruction

  33. Test and Set (P205) function testset ( var i:integer ) : boolean ; begin if i = 0 then begin i := 1; testset := true; end else testset :=false; end. • Notes: when i=0 presents resource is free. When i=1 presents resource is used，

  34. Application(fig 5.7a) program mutualexclusion; const n= …; (*number of processes*); var bolt: integer; procedure P( i:integer); begin repeat repeat {nothing} until testset(bolt); <critical section> bolt:=0; <remainder> forever end; begin (*main program*)bolt:=0; parbegin p(1); p(2); …… p(n); parend end.

  35. Exchange(P205) procedure exchange ( var r :register; var m :memory ); var temp; begin temp := m; m := r; r := temp; end.

  36. Application (Fig5.7b) program mutualexclusion const n=…; (*number of processes*); var bolt: integer; procedure P(i:integer) var keyi: integer; begin repeat keyi:=1; repeat exchange (keyi, bolt) until keyi=0; <critical section> exchange(keyi, bolt); <remainder> forever end; begin (*main program*)bolt:=0; parbegin p(1); p(2); …… p(n); parend end.

  37. Characteristics of Hardware Command (P207) Adv. • Simple • Be suitable for multi-processes to share memory in single process or multi processors environment • Be suitable for accessing multi-critical sections. Every critical section can define a variable. Disadv. • Busy for waiting • Maybe induce hungry • Maybe induce deadlock. Exp, when a process, which is in a critical section, is interrupted, then deadlock happens……

  38. Semaphores (OS provide) • Function: Be used to implement mutual exclusion and synchronization • Operations of semaphore: Assuming the semaphore is a integer • Semaphore can be initialed as a no-negative integer • wait(s): s－1; if s＜0, block the correspondent process • signal(s): s＋1; if s≤0, wakeup the correspondent process

  39. Types of Semaphore • General semaphore: Fig5.8 • Binary semaphore: Fig5.9

  40. F5.8 A Definition of Semaphore Primitives Type semaphore= record count: integer queue:list of process –FCFS end; Var s: semaphore

  41. Wait(s): s.count=s.count-1; if s.count<0 then begin place this process in s.queue; block this process end; Signal(s): s.count:=s.count+1; if s.count <=0 then begin remove a process P from s.queue; place process P on ready list end

  42. F5.9 A Definition of Binary Semaphore Primitives Typebinary semaphore= record value:(0,1) queue:list of process –FCFS end; Var s: binary semaphore;

  43. Binary Semaphore WaitB(s): if s.value=1 then s.value:=0 else begin place this process in s.queue; block this process end; SignalB(s): if s.queue is empty then s.value :=1 else begin remove a process P from s.queue; place process P on ready list end

  44. Semaphore • Wait、signal are primitive operations • Wait operation request resources and maybe block the requestor. Signal operation release resources and maybe wakeup the blocked process. • General semaphore is a record. It is composed of an integer and a list of block processes which wait for the resources presented by the semaphore (FIFO) .

  45. Mutual Exclusion by Semaphore (Fig5.10) Program mutualexclusion Const n=…;//number of processes Var s:semaphore(:=1); Procedure P(i:integer); Begin repeat wait(s); <critical section> signal(s); <remainder> forever End; Begin //main program parbegin P1; P2; …. Pn; parend End.

  46. Significance of Semaphore • Mutual exclusion semaphore: request/release the privilege, initial value is 1 • Resource semaphore: request/release resource，initial value s.count =n (n>0) (presents the number of the resources） • s.count≥0:is the number of processes that can execute wait(s) without suspension. • s.count﹤0: the number of processes suspended in s.queue

  47. The Producer/Consumer Problem (P211) • Description: • Producer: One or more producers generate data and put the data into buffer • Consumer: Only one consumer get the data from buffer • Limited: • Buffer can be accessed only by a process(producer or consumer) at a time(mutual exclusion). • Control producer/Consumer access buffer in a rational sequence. Producer could not write data to a full buffer and consumer could not read data from a empty buffer.

  48. Infinite-Buffer producer： consumer ： repeat repeat produce item v; while in≤out do {nothing}; b[in] := v; w := b[out]; in := in + 1； out := out + 1； forever; consume item w; forever;

  49. An Incorrect Solution to the Infinite-Buffer P/C Problem Using Binary Semaphore(Fig5.13) Program producerconsumer Var n:=0 integer; s:(*binary*)semaphore(:=1) delay:(*binary*)semaphre(:=0) Procedure producer Begin repeat produce; waitB(s); append; n:=n+1; if n=1 then signalB(delay); signalB(s); forever End; Procedure consumer; Begin waitB(delay); repeat waitB(s); take; n:=n-1; signalB(s); consume; if n=0 then waitB(delay) forever End;

  50. Incorrect Solution Begin (*main program*) n:=0; parbegin producer; consumer; parend; End.

More Related