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

Presentation on theme: "Cooperating sequential processes Felipe Bernal Isabel Virag Marcus Vinson Kevin Capers Manuel Arredondo By E. Dijkstra."— Presentation transcript:

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

An Example of a Priority Rule Felipe Bernal

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

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.

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

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)

Status Variables Desire Buffman Number of queuing options Number of buffered units needed for 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

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.

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;

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.

An Example of Conversations Isabel Virag

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.

Requirements for Total Construction Features - 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)"

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"

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".

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.

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. …Requirements

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“ 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.) Message Interpreter

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. Problems we are still facing:

Keep three points in mind: a)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 increases linearly 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 leave this partial state should inspect if some waiting process should go on. 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." 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]"." Process States

We introduce a single variable, called "comvar" to distinguish between communication states. Three aspects: 1)availability of the communication possibility for M-messages. 2)acceptability of the incoming messages. 3)operator priority for incoming messages. 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.“ 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." 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. Communication States

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. Writing the program

Improvements of the Previous Program Marcus Vinson

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.

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”.

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. Process i Interpreter: asknum = i comvar = 2 Sending Q or M Communication facility open for an Answer Wait Receive and Interpret Message From Operator procvar[asknum] = answer state Process i No mutual exlusion

A. Comparing Message flows between Processes and Message Interpreter In the flow from processes to message interpreter: o 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. Process i Interpreter: asknum = i comvar = 2 Sending Q or M communication facility open for an Answer Wait Receive and Interpret Message From Operator operanswer[asknum] = answer Process i Mutual exclusion set procvar[asknum] = answer state

Answer array: – integer array operanswer[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. A. Comparing Message flows Continued

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 Basic1. “asknum” 2. “comvar”, “procvar”2. “operanswer” 3. “incoming message”, “procsem”

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.

Proving the Correctness

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

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

Operator Delays response Receiving Answers: Region 2

Message Interpreter

The Problem of the Deadly Embrace Kevin Capers

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”

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

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

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

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

THE BANKER’S ALGORITHM

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

Questions In order for the Banker’s Algorithm to work it needs to know three things: 1.What is the most of a resource that a process could possibly request? 2.How much of the resource the process is currently holding? 3.How much of the resource the system currently has available

Solutions The solutions are simple: 1.The system needs to make sure that it always has enough resources in case a process does make an additional request after its initial request 2.This would determine how much more of the resource this process can borrow 3.Available resources must be known in order to avoid running into the problem of The Deadly Embrace

The Banker’s Algorithm Applied Manuel Arredondo

The Banker’s Algorithm Applied The analogy of the banker and the loans can be carried over to disk usage and memory allocation: florins  processes. “Banker”  software which manages the use of a magnetic tape deck, “loaning a florin” could mean the permission to use one of the tape decks

The “banker” first calculates what happens if request is executed immediately if the situation is SAFE then he proceeds. Otherwise, the requester has to WAIT for availability. For a successful “loan” to occur, the resource must be requested and there must be enough of it to satisfy the entity which needs it.

implementation Florin number- each process has this variable, which contains the number of florins borrowed. Each florin itself has a variable identifying which customer it was borrowed to. Cusvar- state variable for each customer. 1 is for (I want to borrow”), 0 otherwise. Florvar- each florin has a state variable  1 is for anxious to get borrowed, 0 other wise Each customer has a binary semaphore “Cussem”; each florin has a binary semaphore “flosem”

So if the value of cusvar[j] of the current process is 1, the “banker” checks if its possible to provide customer with service: Next, it checks which “florin” is available to be borrowed and changes state variables accordingly.

Concluding Remarks 1.Human mind has a hard time thinking in terms of processes evolving in time. It is easier for us to attach meanings to the values of identified quantities. 2.Concurrent programming & multiprogramming are basically different implementations of the same logical structure

Example 1 i:= 10; LO: x:= sqrt(x); i:= i-1; if i> 0 then goto LO When analyzing this code, we naturally bind i to the meaning “the number of times sqrt(x) has to run” (ten times). However in reality, this is not true at all times during the execution. Therefore, our definition does not apply at all the stages of the process

Example 2 If a variable “wife number” is created. The value zero can be used for a “single” status. Even though this technique is commonly used. This violates/modifies the precise definition of the variable. Therefore, the author suggests creating a Boolean “married” to describe status. This would put less load on our human brain.

Concurrent Programming: more than one processor working on the same job Multiprogramming: single processor running multiple threads. Concurrency deals with division of space and Multiprogramming with division of time. Different versions of the same idea, in both cases it has to be defined how a number of processes cooperate with each other to achieve their task.

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

Similar presentations