Cooperating sequential processes

1. Cooperating sequential processes By E. Dijkstra Felipe Bernal Isabel Virag Marcus Vinson Kevin Capers Manuel Arredondo

2. An Example of a Priority Rule Felipe Bernal

3. An example of priority rule • Previous Section: • Use of general semaphore to couple a producer and a consumer via a bounded buffer • Applicable only when the ‘portion’ is at the same time a convenient unit of information. • This section considers producers that offer portions of different sizes

4. An example of priority rule • The size of the portions is given in information units • The capacity of the buffer is also given in information units • The size of the portion offered determines whether the buffer will be able to accommodate the next portion.

5. An example of priority rule • Bound Buffer: • Producer may have to wait before it can offer a portion (Variable sized portions can also imply that there is free space in the buffer but insufficient for the portion concerned) • Requirement: • The producer wishing to offer the larger portion gets priority over the producer wishing to offer the smaller portion to the buffer. • Two equals result in don’t care

6. An example of priority rule -When a producer has to wait, because the buffer cannot accommodate its portion, no other producers can therefore add their portions until further notice • Example: Producer (1) Consumer (5) Producer (3) Buffer Producer (2)

7. Status Variables • Number of buffered units neededfor the portion it could not add to the buffer • Takes care of the mutual exclusion of buffer manipulations • Semaphore that signals the presence of a next portion to the consumers • Desire • Buffman • Number of queuing options

8. Status Variables • Number of free buffer units • Buffer blocking • Semaphore to signal back to producers free coming buffer space • Integer value which states when no further additions to the buffer can be made until further notice.

9. Code Summary: Producer Add a new portion to the buffer directly or indirectly: If ( buffer blocking = 0 and number of free buffer units ≥ portion size ) decrease "number of free buffer units" AND add the portion to the buffer. Else (Wait) coded by: desire[n] = portion size buffer blocking increased by one;

10. Code Summary: Consumer Takes a portion and increases the number of free buffer units Test: if ( buffer blocking > 0) (false if no producer is waiting for free space just created) -looks for the maximum value of "desire" - If this is not too large the corresponding producer has to go on End Go back to test to see whether more sleeping producers should be woken up.

11. An Example of Conversations Isabel Virag

12. An Example of Conversations -More complex example: One of the cooperating processes is now a human being (as opposed to a machine) -operator is connected via a "semi-duplex channel" • duplex stands for two way communication, i.e. keyboard and printer) • 'semi' specifies that it can only transmit in one direction at a time.

13. Requirements for Total ConstructionFeatures - N identical processes • Each process can ask a single question, called "Q1“ to which the operator may give one of two possible answers, called"A1" and "A2".  - All N processes use the same communication channel. The operator must be able to correctly identify each process: The i-th process identifies itself when posing the question"Q1(i)"

14. Channel sharing between processes results in: - No two processes can ask questions simultaneously. This must be taken care of behind the scenes by mutual exclusion: • If two questions are asked, an answer from the operator specifies which question it is answering by adding an id process like: • A(1) or A2(1) •  Alternatively, make the question be followed by its answer, forming a critical occurrence. Answer would be either "A1" or "A2"; forming two kinds of conversations: "Q1(i),A1" "Q1(i), A2"

15. Features 1. The individual processes may wish to use the communication channel for single-shot messages —"M(i)" without expecting an answer. 2. The operator must have the possibility to postpone an answer. For this:  We introduce an answer called "A3", "The channel becomes free again, but the conversation with the process concerned remains unfinished."  To reopen the conversation, use:  "A5(i)"  "A4" indicates that the process should continue in the same way as after "A1", while "A5" prescribes the reaction as to "A2". 

16. Requirements Possible forms of conversation are now: a) "Q1(i), A1" b) "Q1(i), A2" c) "Q1(i), AT3" - - - "A4(i)" d) "Q1(i), AT3" - - - "A5(i)" 3. A4-and A5-messages must have priority over Q1- and M-messages.  i.e. While the communication channel is occupied, processes might want to use the channel, but the operator might also be in need of it. As soon as the channel becomes available, the operator should have the priority to use it first.

17. …Requirements We assume that: a) the operator can give externally an incoming message: he can use it to announce an answer message b) the operator can detect whether a message is accepted This reserves the communication channel for an A4 or A5 message. However, in case the situation changes, we implement "A6“ enables the operator to withhold the A4 or A5. Final feature of the message interpreter is the applicability test: • Operator mistakes  message is rejected as non-applicable. • The interpreter  returns to a state in which the correct answer can be given.

18. Message Interpreter To implement the message interpreter: 1)Aside from the N processes; new process: "message interpreter“ 2) Interpretation of a message always implies, besides the message itself, a state of the interpreter. • Coded via the (common) state variable "comvar“ • Using the private semaphore "incoming message“

19. Message Interpreter 3) For the N processes: • use an array "procsem" of private semaphores • and an array "procvar" of state variables (the different processes can communicate with each other, with the message interpreter and vice versa.) 4) Introduce: • A single binary semaphore "mutex caters for the mutual exclusion during inspection and modification of the variables. 5)Never use the binary semaphore "mutex" as: "mutex= 0" to signal that the channel is occupied. (causes a problem if the N processes have two channels at their disposal.)

20. Problems we are still facing: a) what structure should we give to the N + 1 processes? b) what states should we introduce? • The problem is that the two points are interdependent. One can’t be done without affecting the other • We can only make the programs if we know what inspections and operations need to be created.  It is easier to conceive first the states (being statically interpretable) and then the programs.

21. Process States Keep three points in mind: • State variables should have a meaning when mutex is = 0; A process must leave the critical section before it starts to wait for a private semaphore.  b) The combined state variables specify the total state of the system. If some aspect of the total state increaseslinearly with N, it is easier to conceive that part as equally divided among the N processes. c) If a process decides to wait on account of a certain (partial) state, each process that makes the system leavethis partial state should inspect if some waiting process should go on. 

22. Process States Set of appropriate states: Start with the element "procvar[i]", describing the state of process i. 1. procvar[i] = 0 "the homing position":  Indicates process i does not require any special service from either the message interpreter or any one of the other processes. 2. procvar[i] = 1 "On account of non-availability of the communication channel, process i has decided to wait on its private semaphore."

23. Process States 3. procvar[i] = 2 "Question "Q1(i)" has been answered by "A3“ with respect to process I, and the operator has postponed his final decision.“ The postponement must be represented because it can hold for an undefined period of time. 4. procvar[i] = 3 "Q1[i]" has been answered by "A1" or by "A3"- - -"A4[i]" 5. procvar[i] = ""Ql[i]" has been answered by "A2" or by "A3"- - -"A5[i]"."

24. Communication States We introduce a single variable, called"comvar" to distinguish between communication states. Three aspects: • availability of the communication possibility for M-messages. • acceptability of the incoming messages. • operator priority for incoming messages.

25. Communication States • comvar = 0 "The communication facility is idle"  equally available for both processes and operator. • comvar = 1 "The communication facility is used for an M-message or a Q1-question". (the value of "comvar" must  not equal 0, because the communication facility is not available for the processes. ) • comvar = 2 "The communication facility is reserved for A1 ,A2 or A3 answer.“ 

26. Communication States • Taking the third requirement into consideration will lead to a duplication of (certain) states. Therefore, we can introduce a new state: • comvar = 3 (state 1 duplicated) "As "comvar = 1" with operator priority requested.“ When the transition to "comvar = 3" occurred during a M-message, the operator could get his opportunity. • However, if the transition to "comvar = 3" took place during a Q1-question, the priority can only be given to the operator after the answer to the Q1-question. Therefore: • comvar = 4 (state 2 duplicated) "As "comvar = 2", with operator priority requested."

27. Communication States • comvar = 5 "The communication facility is reserved for, or used upon instigation of the operator."  These messages will be announced to the message interpreter while "comvar" is = 0. If we do not wish that the entire interpretation of these messages be done within the same critical section, the message interpreter can break it open. Therefore "comvar" is ≠ 0.

28. Writing the program Before starting to write the program, we must bear in mind: Availability of the communication facility is the great (and only) bottleneck. We must see to it, that every process that ends a communication facility occupation decides upon its future usage.

29. Improvements of the Previous Program Marcus Vinson

30. I. Improvements of the Previous Program • The previous program was just a first virsion towards correctly handling cooperating processes. • Dijkstra presents it to help visualize the development of a solution. • Now the complexity of the program is analyzed, and he tries to embellish better clarity and possibly efficiency into the program.

31. A. Comparing Message flows between Processes and Message Interpreter • In the flow from processes to message interpreter: • “asknum” tells interpreter which process is asking a question. • “asknum” is set and inspected outside of critical sections. • Not accessed by other processes or interpreter when communication facility is reserved for a Question or Message ( comvar = 1 ). • In the flow from the message interpreter to a process: • Interpreter sends back the nature of the operator’s answer via “procvar”.

32. A. Comparing Message flows between Processes and Message Interpreter • Concerns with Procvar holding the answers: • 1. “procvar” inspection can take place outside critical sections. • 2. It is superfluously set to zero after inspection. Interpreter: asknum = i comvar = 2 Process i Sending Q or M Communication facility open for an Answer Receive and Interpret Message From Operator Wait No mutual exlusion procvar[asknum] = answer state Process i

33. A. Comparing Message flows between Processes and Message Interpreter • In the flow from processes to message interpreter: • Suggested change: • Introduce: integer array “operanswer” • Holds the answers for each of the N processes. • Set within critical sections ensuring no interruptions in message delivery. Interpreter: asknum = i comvar = 2 Process i Sending Q or M communication facility open for an Answer Receive and Interpret Message From Operator Wait Mutual exclusion set operanswer[asknum] = answer Process i procvar[asknum] = answer state

34. A. Comparing Message flows Continued • Answer array: • integerarrayoperanswer[1:N] • Benefits: • Separate variables for a processes state and its received answers. • The number of possible values of “procvar” does not increase even if the number of possible answers to the question Q1 is increased.

35. B. Variable Hierarchy • For greater clarity, the common variables can be separated into two groups. • The groups reflect a hierarchy in the way in which they are used and in terms of “basicness”. State Variables:Transmission Variables: 1. “mutex” = Most Basic 1. “asknum” 2. “comvar” , “procvar” 2. “operanswer” 3. “incoming message” , “procsem”

36. C. Code Regions: Actions Occur Ith Process: • Region 1: send M message; P(mutex); select new comvar value; V(mutex); • Region 2: asknum:= n; • send Ql(n); • P(mutex); comvar:= 2; V(mutex); P(procsem[n]); • Region 3: if operanswer[n] = 1 then Reaction 1 • else Reaction 2; • End • Region 4: begin operator priority:= true; • leave: V(mutex); goto wait; end if comvar ≠ 2 then goto Region 6; • Region 5: V(mutex); collect message; • if message ≠ A1 and message ≠ A2 and message ≠ A3 then goto wait; • i:= asknum; • if message = A1 then operanswer[i]:= 1 else • if message = A2 then operanswer[i]:= 2; • P(mutex); • if message = A3 then procvar[i]:= 2 else • signal to i: V(procsem[i]); • preleave: select new comvar value; goto leave; • Region 6: if comvar = 0 then comvar:= 3; • for i:= 1 step 1 until N do pvcopy[i]:= procvar[i]; • V(mutex); collect message; • if message = A6 then begin P(mutex); gotopreleave end; • if message ≠ A4(prmcess number) and message ≠ A5(process number) then • goto wait; • i:= "process number given in the message"; • if pvcopy[i] ≠ 2 then goto wait; • operanswer[i]:= if message = A4 then 1 else 2; • P(mutex); procvar[i]:= 0; goto signal to i • end • Region 1: Sending an M-message • Region 2: sending a Q1(i) Region 1: send M message; P(mutex); select new comvar value; V(mutex); Region 2: asknum:= n; • send Ql(n); • P(mutex); comvar:= 2; V(mutex); P(procsem[n]); Region 3: if operanswer[n] = 1 then Reaction 1 • else Reaction 2; • End Region 4: begin operator priority:= true; leave: V(mutex); goto wait; end if comvar ≠ 2 then goto Region 6; Region 5: V(mutex); collect message; • if message ≠ A1 and message ≠ A2 and message ≠ A3 then goto wait; • i:= asknum; • if message = A1 then operanswer[i]:= 1 else • if message = A2 then operanswer[i]:= 2; • P(mutex); • if message = A3 then procvar[i]:= 2 else signal to i: V(procsem[i]); preleave: select new comvar value; goto leave; Region 6: if comvar = 0 then comvar:= 3; • for i:= 1 step 1 until N do pvcopy[i]:= procvar[i]; • V(mutex); collect message; • if message = A6 then begin P(mutex); gotopreleave end; • if message ≠ A4(prmcess number) and message ≠ A5(process number) then • goto wait; • Region 3: reacting to operanswer[i] MessageInterpreter: • Region 4: ignoring messages • Region 5: expecting A1, A2, A3 • Region 6: expecting A4[i] , A5 , A6

37. D. Less Fundamental Improvements • “procvar” and “comvar” can be simplified to represent the fundamental states. • New meanings for “procvar” and “comvar”. procvar[i] = 0 homing position procvar[i] = 1 waiting for M or Q1(i) procvar[i] = 2 waiting for the answer "A4(i)" or "A5(i)". comvar = 0 homing position (communication facility free) comvar = 1 communication facility for M or Q1 comvar = 2 communication facility for A1, A2 or A3 comvar = 3 communication facility for A4, A5 or A6.

38. Proving the Correctness

39. I. Proving the Correctness • A picture of the overall program: • Critical sections: “mutex” locks inspection and modification of the state variables and it prevents ambiguous use of the transmission variables. • The other state variables: They ensure that the Regions are properly sequenced based on the states of the processes and facilities. • Transmission Variables: Regions which assign information to transmission variables immediately followed by regions which inspect the transmission variables.

40. Sequence Example: Interpreter: Process I: Process n: Region 2: If comvar = 1 Wait… Region 4: If comvar = reserved then Block message Region 2: If comvar = 0 then Reserve facility Send Message.C Region 5: If comvar = 2 then Operanswer[i] = answer Awake process[asknum] Region 3: Inspect operanswer. Continue.

41. Receiving Answers: Region 2 Operator Delays response

42. Message Interpreter

43. The Problem of the Deadly Embrace Kevin Capers

44. What is The Problem of the Deadly Embrace? • Extension of the principle: “No two persons can use a single compartment of a revolving door at the same time”

45. Example • Consider a program describing some computational process to be performed by a computer. • During the time it takes to execute the process, information must be stored on the computer. • But we are restricted by: • The maxinum demand on storage space and • The process will eventually end

46. We assume that the available store has been subdivided into fixed size “pages”(in this case they are equivalent) • The actual demand on storage space a process needs may be a function varying in time • We assume that the processes request from and return to the available store

47. We now request that a process is able to finish once it has begun (no matter how long it takes) • If the computer has to complete processes one after the other, the maximum demand must not exceed the total storage capacity • However, if it can execute multiple processes simultaneously, new processes may be added as long as the demand for storage does not exceed the maximum available storage

48. There are times when one process can continue only if another process is killed first • This is called “The Deadly Embrace”

49. The Banker’s Algorithm

50. What Is It? • An algorithm is run by the operating system whenever a process requests resources • Avoids deadlock by denying or postponing the request if the OS determines that accepting it could put the system in an unsafe state