Concurrency Principles

Transcription

1 Concurrency Concurrency Principles Where is the problem Interleaving: Multi-programming: Management of multiple processes within a uniprocessor system, every system has this support, whether big, small or complex. Distributed Processing: Management of multiple processes executing on number of distributed computer systems, for example clusters. (Do not Share Memory) Multi-processing: Management of multiple processes within a multi-processor system, servers and works stations. (Shared Memory) What is common among these categories? Concurrency: execution of multiple processes no mater on single or more processing elements. In a single processor case multiple processes are interleaved in time to provide the illusion of simultaneous execution of these processes. Although, it is not really parallel processing but there are benefits using such technique, apart from having overheads involved in switching of these processes. Issues: Basically, it is not possible to predict the speed of execution of processes Optimal allocation of resources is not possible by the o/s. Sharing of global variables. Pseudo Code for Demonstration: Suppose we have two or more applications reading input from the keyboard and putting the result on the screen. It would make sense to have the same procedure for all these applications and obviously it will be loaded into the global address space. Pseudo Code: function_test ( string charact) readin (input_variable, keyboard); charact = input_variable; readout (charact, display); exit; 2 P Process P has called function_test and have just read (X) the input and being interrupted, so charact = X; P P resumed it will display what? P2 Process P2 has called function_test and allowed to run till end with input Y, e.g., charact = Y. So the first charact is lost, what can we do to prevent such problem (mutual exclusion), the above example is for uni-processor system, but similar problem can occur on a Multiprocessor platform while sharing of resources, for example, accessing the same location (variable) by two or more processes running on different machines. The problem is with that particular region: where both processes wants to enter. 3 How to Achieve Mutual Exclusion Basics to get mutual exclusion: Conditions for Mutual Exclusion Only one process is allowed into its critical section A process which may stop execution in non critical section must not affect/interfere with others A process should not be delayed indefinitely requiring access to critical section Any process must be allowed to enter into critical section without delay, if no process is in critical section No assumptions about speeds or numbers of CPUs to be considered A process should remain in the critical section for a finite time only Operating System Concerns What are the issues o/s has to consider for concurrency: O/S must keep track of all the processes (normally it is done through PCB s) O/S must allocate and de-allocate the resources for the processes. Which includes processor time, memory, files and i/o devices. Protection of resources against unintended interference from other processes. Result of a process must be independent of the speed at which the execution is taking place relative to the speed of other concurrent processes. Let us explain this last step in more detail: Degree of Awareness Unaware of others Indirectly aware of others Relationship Competition Cooperation by sharing Influence on others. Result is independent of others 2. Timing may be affected. Result is not independent of others 2. Timing may be affected Problems. Mutual Exclusion 2. Deadlock 3. Starvation. Mutual Exclusion 2. Deadlock 3. Starvation 4. Data Coherence Directly aware of others Cooperation by communication. Result is not independent of others. Deadlock 2. Timing may be affected 2. Starvation Fall 27 -

2 Mutual Exclusion has cost Deadlock Starvation Mutual Exclusion Suppose two processes P and P2 are to accomplish a task by using two resources R and R2 And assume o/s has allocated R to P and R2 to P2. What happened next? P P2 is starved P2 P3 P P2 Deadlock Starvation R R Waiting (for ever) R2 P P3 P P3 P P Data Coherency Dekkers Algorithm Modification In addition to deadlock and starvation another requirement may also be necessary, for example, suppose an application needs that a must condition should always be in placed say: a = b In other words any process updating a must update b or vice versa e.g., P: a = a - ; b = b - ; P2: b = b * 2; a = a * 2; Which is fine if the consistency is achieved, but consider the following situation and both impose mutual exclusion; say a=b= 2; P: a = a - ; P2: b = b * 2; P: b = b - ; P2: a = a * 2; Which clearly demonstrate that a = b does not hold any more. There is a strict alternation rule ME is guaranteed Consequences: Execution is dictated by the slowest of the two If one is lost other one is blocked for ever Dictated by the slowest of the two No guarantee of Mutual Exclusion 2 Fall 27-2

3 Modification 2 Modification 3 Correct Solution As we have observed that knowing the state of other processes is not enough to make our problem workable, basically one needs an order the way processes proceeds. Dictated by the slowest of the two Guarantee Mutual Exclusion Deadlock, if both has set the Flag to true before checking others Flag status 3 Dictated by the slowest of the two Guarantee Mutual Exclusion Deadlock? Almost there 4 Dictated by the slowest of the two Guarantee Mutual Exclusion No Deadlock 5 Peterson s Solution Hardware Mutual Exclusion Mutual Exclusion using Instructions Peterson s solution is similar but more elegant as the text says: Mutual exclusion can also be implemented in Hardware by using either interrupt handling or through special machine instructions: Interrupt Disabling: Just before entering the critical region, forcing interrupt disabling will ensure ME Potentially system performance is degraded No support for multi-processor system architecture Machine Instruction: Basically two actions are performed in one cycle for these type of instruction atomically, for example, read and write, reading and writing. Therefore, one can use them as they cannot be interrupted during these actions. Merits & Demerits of Machine Instruction Approach Easy to implement Support for any number of processors Multiple Critical section support (By using different variables) Busy waiting (performance degradation) Starvation is possible Deadlock is possible Test and Set Instruction Boolean testset (int a) if (a == ) a = ; return true; else return false; Exchange Instruction Exchanges the contents of a register with a memory location, obviously during this access to the memory location is blocked. void exchange (int register, memory) int temp; temp = memory; memory = register; register = temp; Fall 27-3

4 ME using testset ME using exchange s n number of processes bolt Shared variable (int) Function_me (process) while true while (!testset (bolt)) be happy and do nothing enter critical section set bolt to ; do remaining part Initially bolt is set to, any process finding it zero will enter into the critical section, obviously all others will go into be happy loop. Once that process leaves its critical section any other process finding bolt zero will immediately go into its critical section and so on. n number of processes bolt Shared variable (int) Function_me (process) key local variable (int) while true key = ; while (key!= ) exchange (key, bolt); be happy until you get bolt zero enter critical section exchange (key, bolt); do remaining part Initially bolt is set to, any process finding it zero will enter into the critical section, but this time it will be through the local variable and the bolt exchange mechanism of the exchange instruction. After completing its job, bolt is again set to through the exchange instruction. Design of an o/s as sequential processes with a reliable mechanism of support for cooperation. Dijkstra proposed a solution based on the fundamental principle of cooperation based on signals, so that a process can be forced to stop at a required place and later starts when instructed through a signal. These signals are called semaphores, to transmit a signal the process executes signal (s) and to receive a signal it executes wait (s). Therefore, if the corresponding signals are not transmitted the process is suspended till the transmission takes place. Properties: It is initialized to a non negative value Wait operation decrements semaphore value, if it goes negative the corresponding process is blocked Signal operation increments semaphore value, if the value is not positive, process can be unblocked from the suspended list. Signal and Wait are atomic (cannot be interrupted) Primitives Binary Primitives Mechanism (Strong s) could be declared as a simple structure having a variable declaration, may be an integer for count and another variable/structure for a process queue. wait (s) count = count - ; if count < put the process in queue block the process signal (s) count = count + ; if count get a process from the queue unblock the process and put it in ready queue if count == count = ; else put the process in queue block the process if queue is empty count = ; else get a process from the queue put it in ready queue Process A s = Process B s = C D B A C D B A C Process C s = Process D s = -3-3 D B A Critical Section (if count is zero) B Process D s = - - A C B A Process D s = -2-2 C The order of removal from the queue is not defined, FIFO etc., the only requirement is that no process should wait indefinitely in the queue. Example set count = ; which process will enter into critical section? Process D s = B A C Fall 27-4

5 Mutual Exclusion using s The following pseudo ops can be used for the mutual exclusion problem There could be n processes Each process executes wait before entering to its critical section Positive value means it can enter into critical section If the value becomes negative, process is suspended s = ; n = number of processes ; Process () loop wait (s) critical section signal (s) remaining execution As the semaphore is initialized to, the first process executing wait will enter into its critical section and will set the value of s to. Any other process may attempt to enter, resulting in decrementing s to a negative value and suspension of that process. Ultimately, the process initially entered into its critical section will depart with incrementing the value of s, resulting one of the suspended process to be released. Next a possible sequence of events for 3 processes are shown to achieve mutual exclusion. Mutual Exclusion using s Lock A B C Wait (lock) Normal Execution Wait (lock) B Wait (lock) B C signal (lock) C Blocked signal (lock) Critical Section signal (lock) First Time only Produce Producer Consumer Problem (Binary) waitb(s) Inset Inset n = n + If If n == == Critical Section waitb waitb (delay) waitb(delay) waitb(s) Take Take n = n -- (s) consume If If n == == Correct Solution? (s) waitb waitb (delay) Producer Consumer Possible Scenario Producer Consumer Problem (Binary) Producer Consumer Problem (BB) Producer Consumer s n Delay n=n+ If n== then waitb (delay) waitb (delay) Produce waitb(s) Inset Inset n = n + If If n = WaitB (delay) (s) Previously for this problem an infinite buffer was consider, now for realistic situations one has bounded buffer (BB) some thing like a circular buffer, therefore, it can be implemented in the following way: Producer: Consumer: Loop Loop produce if (in == out) do nothing, remain here 8 9 n=n- if ((in + )%n) == out do nothing, remain here put[in] take[out] out = (out + )%n n=n+ Critical Section in = (in + )%n consume 2 If n== then waitb (delay) 3 out in 4 5 If n== then waitb (delay) First Time only 6 n=n- n = n If n== then waitb (delay) waitb(delay) waitb(s) Take Take (s) consume If If m = m = n WaitB (delay) [] [2] [3] [4] [5] [6] [n] n=n- - - Correct Solution filled slots Fall 27-5

6 Barbershop Problem used in the Problem Unfair Barber max_capacity = 2, sofa = 4, barber_chair = 3, coord = 3; A classical problem similar to a real operating system for the access of different resources. Problem definition: Three chairs. Three barbers. Waiting area having capacity for four seats and additional space for customers to stand a and wait. Fire code limits the total number of customers (seating +standing). Customer cannot enter if pack to capacity. When a barber is free, customer waiting longest on the sofa can be served. If there are any standing customer, he can now occupy the seat on the sofa. Once a barber finished haircut, any barber can take the payment. As there is only one cash register, so payment from one customer is accepted at a time. Barber(s) time is divided into haircut, accepting payment and waiting for customers (sleeping). max_capacity sofa barber_chair cust_read finished leave_b_chair payment receipt coord wait Customer waits for room to enter shop Customer wait for seat on sofa Customer wait for empty barber chair Barber waits until a customer is in chair Customer waits until his haircut finished Barber waits until customer gets up Cashier waits for a customer to pay Customer waits for a receipt for payment Wait for a barber resource to be free to perform either haircut or cashiering function Signal Exiting customer signals to the waiting customer for entry Customer leaving sofa signals to waiting standing customers Barber signals when his chair is empty Customer signals that he is in the b chair Barber signals once he finished haircut Customer signals barber when he gets up Customer signals cashier that he has paid Cashier signals the acceptance of payment Signal that a barber resource is free cust_ready=, finished =, leave_b_chair =, payment =, receipt = ; void customer ( ) void barber ( ) wait (max_capacity); enter_shop ( ); wait (sofa); wait (cust_ready); sit_on_sofa ( ); wait (coord); wait (barber_chair); cut_hair( ); get_up_from_sofa(); signal (coord); signal (sofa); signal (finished); sit_in_barber_chair(); wait (leave_b_chair); signal (cust_ready); signal (barber_chair); wait (finished); leave_barber_chair (); signal (leave_b_chair); pay( ); signal (payment); wait (receipt); exit_shop( ); signal (max_capaity); void main ( ) customer( ); barber ( ); void cashier ( ) wait (payment); wait (coord); accept_pay( ); signal (coord); signal (receipt); 3 32 cashier( ); 33 Fair Barber Monitors Monitor Structure Things can be improved interms of timing by using some more semaphore as; int count; mutex =, mutex2 = ; max_capacity = 2, sofa = 4, barber_chair = 3, coord = 3; cust_ready=, finished =, leave_b_chair =, payment =, receipt = ; void customer ( ) void barber ( ) void cashier ( ) int custnr; int b_cust; wait (max_capacity); enter_shop ( ); wait (payment); wait (mutex); wait (cust_ready); wait (coord); count = count + ; custnr = count; signal (mutex); wait (mutex2); accept_pay( ); wait (sofa); dequeue (b_cust); signal (coord); sit_on_sofa ( ); signal (mutex2); signal (receipt); wait (barber_chair); wait (coord); get_up_from_sofa(); Cut_hair( ); signal (sofa); signal (coord); sit_in_barber_chair(); signal (finished[custnr]); wait (mutex2); wait (leave_b_chair); enqueue(custnr); signal (barber_chair); signal (cust_ready); signal (mutex2); wait (finished[custnr]); leave_barber_chair (); signal (leave_b_chair); pay( ); signal (payment); wait (receipt); exit_shop( ); signal (max_capaity); s exhibit flexible and powerful mechanism for enforcing mutual exclusion. But potentially it can produce incorrect program because of the scattering of the operation. Monitors are another option which is basically a programming language construct providing equivalent functionality to the semaphores but easier to implement and control. A monitor is a software module consists of one or more functions (initializing sequence and the local data). Characteristics of a Monitor with Signal Local data is only accessible to monitor s functions. A process can enter into monitor by calling one of its function. Only one process is allowed to execute in monitor at any given time, any other process that may have invoked the monitor remains suspended till it becomes available. It is basically this characteristics which makes mutual exclusion possible. Because of the previous condition data variables in the monitor will also be accessible by only one process at a time, therefore, shared variables can be protected by placing them in the monitor. Synchronization is also provided in the monitor for concurrent processing through cwait (c) and csignal (c) operations. Monitor waiting area condition c condition cn urgent queue cwait (c) cwait (cn) csignal(c i ) Monitor Local Data Condition Variables Function () () Function () () Initialization Code Queue for Entering Exit Fall 27-6

7 Producer-Consumer Solution using Monitor Modified Monitor Modified Monitor Code char buffer [n]; int nextin, nextout; int count; int notfull, notempty; nextin = ; nextout = ; count = ; void append (char x) if (count ==n) cwait (notfull); buffer[nextin] = x; nextin = (nextin + ) % n; count ++; csignal (notempty); void producer ( ) char x; produce (x); append (x); void take (char x) if (count == ) cwait (notempty); x = buffer[nextout]; nextout = (nextout + )%n; count --; csignal (notfull); void consumer ( ) char x; take (x); consume (x); In the original version it requires that if there is at least one process in the condition queue, a process from that queue runs immediately when another process issues a csignal for that condition. Therefore, csignal issuing process either immediately exit monitor or be suspended in the monitor. There are two limitations with this approach: if csignal issuing process has not finished with the monitor, two additional process context switches are need (one to suspend, another to resume). A perfect reliable process scheduling is a must condition. For example, when a process issue csignal a process from the condition queue must be activated before any chance of scheduler allowing a process to enter into the monitor. Improved development uses cnotify primitive instead of csignal, meaning that when a process issues a cnotify (x), it tells the x condition queue and continue executing. The benefit of notifying the condition queue is that process residing at the front of queue will resume at some convenient time when monitor is available. On the other hand it is not guarantee that another process will not enter in the monitor before the waiting process. For that instead of if statement, a while statement is used, which ensures the above constraint to be solved. It is just one extra evaluation of the condition but it saves two process switches and no constraints on when a process must run after a notify. The improved version is less prone to errors and also it looked more modular approach to program construction. (HOARE & LAMPSON/REDELL) void append (char x) while (count ==n) /* instead of if statement */ cwait (notfull); buffer[nextin] = x; nextin = (nextin + ) % n; count ++; cnotify (notempty); void take (char x) while (count == ) /* instead of if statement */ cwait (notempty); x = buffer[nextout]; nextout = (nextout + )%n; count --; cnotify (notfull); Message Passing Design Issues in Message Passing Design Issues in Message Passing For any two processes to interact, it is essential to have synchronization and communication. Synchronization Addressing Format Synchronization is for Mutual Exclusion Communication is for exchange of information Queuing Message Passing can provide both Receive Send Direct Indirect Content Length Fairest of all Priority Communication Synchronization Send Added advantage; it works for distributed systems, multi-processors shared memory systems and uni-processors. Comes in many flavors. Essentially has this minimum set of operations: Blocking Non Blocking Test for Arrival Blocking Non Blocking Receive Explicit Static Dynamic Ownership Fixed Variable send (destination, message) receive (source, message) Implicit Fall 27-7

8 Synchronization Addressing Indirect Addressing Receiver cannot receive until a message is sent to him. Possible Discipline for send & receive Blocking send - Blocking receive Both sender and receiver is blocked until message is delivered, this is tight synchronization scheme and called rendezvous. Non Blocking send - Blocking receive It is a useful combination having liberty to send as many messages to different destinations quickly, blocking receive is useful too, as a server process waiting to provide any service to other processes. Non Blocking send - Non Blocking receive Non blocking send is the most natural option for many systems. Let us consider the simplest example case of printing request, it will be foolish to keep waiting till the printing job finished. The only concern could be in the event of error generation of multiple messages which could lead to use system resources for no productivity. From receive primitive, blocking is the natural option because the requested information has to be received first before proceeding. However, if the message is lost or the sending process have problem to send the requested information, receiver will be blocked may be indefinitely. So may be non blocking, but then one has to ensure that the messages are not lost, may be it can check (test for arrival) for any waiting messages before resuming its processing. Direct Addressing send primitive includes a specific identifier of the destination process. Receive can have two options: Explicit receive: which must designate a sending process, the receiving process must know ahead of time that a message is expected (which may be ok for cooperating processes). Otherwise, it is not possible to anticipate incoming process from different sources. Implicit receive: In which case source parameter of the receive primitive contains a returned value once the receive operation is accomplished. Indirect Addressing Messages are not directly sent to receiver and vice versa, instead they are sent to a shared data structure made of queues (mail boxes) to hold data for some time. The sender and receiver is decoupled and hence provide more flexibility in the use of messages. Number of options can be possible: one to one (could be a private link between two processes), one to many (broadcasting), many to one (client/server) or many to many. The association of processes could be static or dynamic, one to one could be static version, many to one could be dynamic by creating ports may be using connect and disconnect. Generally ports are created and owned by the receiving process, so when the process is destroyed port also goes with it. For a general mail box, operating system can create mail box service and hence owned by the operating system and an explicit command will be required to destroy this mail box. P Q Sending Processes Mailbox Receiving Processes Pn Q P Q Port Sending Processes Pn Message Format Queuing Mutual Exclusion using Message Passing Depends on the objective of the messaging facility and also configuration meaning single machine or distributed system. Fixed length messages: Minimize processing and storage overhead. Variable length messages: Flexible. Message has two parts, header which may contain a type field for distinction among various type of contents, control information for example a pointer field to create linked list of messages, a sequence of of numbers to keep record of the number and order of the messages and also may be priority field. Body is the actual message content. Header Body Typical Message Format Message Type Destination ID Source ID Message Length Control Information Message Contents The simplest and the fairest approach could be FIFO, obviously, it will not work for situation when messages have some urgent priority attached with them. Message can have a priority field based on their type so they will be dealt accordingly. The receiver can inspect the message queue and can decide what he is looking for. Non Blocking send - blocking receive Processes are sharing a mail box mutex Mail box is initialized with a single message with NULL contents Process wishing to enter its critical section first attempts to get a message If mail box is empty, message is blocked Once receiver has message, it can enter into the critical section Message function as a token for processes const int n /* number of processes */ void p (int i) message msg; receive (mutex, msg); critical section; send (mutex, msg); remainder Fall 27-8

9 Producer - Consumer Solution using Message Passing Description Reader - Writer Problem void producer ( ) message pmsg; receive (mayproduce, pmsg); pmsg = produce ( ); send (mayconsume, pmsg); const int capacity = /* buffering */; int i; void main ( ) create_mailbox (mayproduce); create_mailbox (mayconsume); for (int i= ; i<=capacity; i++) send (mayproduce, null); producer; consumer; void consumer ( ) message cmsg; receive (mayconsume, cmsg); cmsg = consume ( ); send (mayproduce, cmsg); const int null = /* empty message */; 49 What happens if more than one process performs receive operation concurrently: If mailbox has a message, it will be delivered to only one process, others will be blocked If mailbox queue is empty, all will be blocked Generally this is true for all message passing facilities. In the previous example, two mailboxes are created, producer send data to the mayconsume mailbox. It serves as a buffer, which is organized as a queue and as long as there is at least one message, consume can consume it. Initially, mayproduce is filled with a number of null messages equal to the capacity of the capacity variable. Number of messages shrinks with each production in mayproduce and grows with each consumption. mayproduce mayconsume 5 Problem Definition: Data (file, memory location or bank of registers) to be shared among processes Couple of reader and writer processes are present with following constraints: No restriction on readers to read data Only one writer can write at one time During writing no reader is allowed to read One must understand that no writer is allowed to read and no reader can write, this is a restricted case, if we consider the general case in which both are allowed to do these functions then any portion of the shared area can be considered critical section. Therefore, a general mutual exclusion solution can be employed. That solution is in general very slow, so here restricted case is typically very efficient. Consider for example a library catalog, ordinary users read the catalog to locate a book and only the librarian can update or change the data. So in the general case every access to the catalog will be consider critical section and only one user will be able to read the data. Which is Going to be very slow indeed. 5 Reader -Writer using Discussion State of Queues Reader has Priority Writer has Priority Reader has priority int readcount; semaphore x = ; int readcount, writecount; semaphore x =, y =, z = ; semaphore wsem =, rsem = ; semaphore wsem = ; void reader ( ) void writer ( ) In this case, writers can be starved as long as one reader is present void reader ( ) wsem is used to enforce mutual exclusion in the reader function Only one writer is allowed to have access, during which no reading and writing by others wait (z); wait (y); wait (x); wait (rsem); writecount ++; When there is no reader, the first one wants to read has to wait on wsem, the subsequent readers don t have readcount ++; wait (x); if (writecount == ) to wait. if (readcount == ) readcount ++; wait (rsem); wait (wsem); if (readcount == ) signal (y); readcount is used to keep track of number of readers. signal (x); wait (wsem); wait (wsem); semaphore x is used to assure that readcount is updated properly. readunit ( ); signal (x); writeunit ( ); wait (x); signal (rsem); signal (wsem); Writer has priority readcount --; signal (z); wait (y); if (readcount == ) readunit ( ); writecount --; The modified version, which guarantee that no reader can access the data once a writer has shown the desire signal (wsem); wait (x); if (writecount == ) to access, obviously, few more semaphores and variables are required. signal (x); readcount --; wait (rsem); if (readcount == ) signal (y); semaphore rsem is used to inhibit readers once a writer wishes to access. signal (wsem); void writer ( ) signal (x); writecount is used to control the setting of rsem. semaphore y is used to assure that writecount is updated properly. Only one reader is allowed to queue on rsem all other will queue on z, because writer will not be able to wait (wsem); jump all of them. writeunit ( ); signal (wsem); Readers only in the system Writers only in the system Both readers and writers with read first Both readers and writers with write first wsem set no queue wsem and rsem set writers queue on wsem wsem set by reader rsem is set by writer all writers queue on wsem one reader queue on rsem all other readers queue on z wsem set by writer rsem is set by reader all writers queue on wsem one reader queue on rsem all other readers queue on z 54 Fall 27-9

10 Reader-Writer using Message Passing Discussion void reader (int i) message rmsg; rmsg = i; send (readrequest, rmsg); receive (mbox[i], rmsg); readunit ( ); rmsg = i; send (finished, rmsg); void writer (int i) message rmsg; rmsg = i; send (writerequest, rmsg); writeunit ( ); rmsg = i; send (finished, rmsg); void controller ( ) if (count > ) if (!empty (finished)) receive (finished, msg); count ++; else if (!empty (writerequest)) receive (writerequest, msg); write_id = msg.id; count = count - ; else if (!empty (readrequest)) receive (readrequest, msg); count --; send (msg.id, ok ); if (count == ) send (write_id, ok ); receive (finished, msg); count = ; while (count < ) receive (finished, msg); count ++; Dr. D. M. Akbar Hussain 55 The controller process actually access the shared data Any process wishing to access the shared data send request to controller OK indicates access granted and finished message indicates completion Controller has three mailboxes for each type of messages Controller process gives priority to the write process request messages Mutual exclusion is forced through count variable, which is initialized to here, indicating maximum number of readers allowed If count >, indicates no writer is waiting, there may or may not be any reader If count =, only write request is outstanding, so allowed till finished message If count <, indicates a writer has launched a request, and waiting to clear all active readers. So only finished messages are serviced 56 Fall 27 -