INTER PROCESS COMMUNICATION Prepared By Dr Vipul Vekariya
INTER PROCESS COMMUNICATION Prepared By: Dr. Vipul Vekariya
INTER PROCESS COMMUNICATION Processes frequently need to communicate with other processes is called the IPC. There are three issues here. How one process can pass the information to other? The second has to do with making sure two or more processes do no get into each other’s way when engaging in their activities. The third concerns proper sequencing when dependencies are present.
Race Conditions Two processes want to access shared memory at the same time.
SECOND EXAMPLE OF RACE CONDITION Void echo() { chin=getchar(); chout=chin; putchar(chout); } ->>> b=1 , c=2 P 1 : b = b+c P 2: c= b+c 4
RACE CONDITION Two or more processes are reading or writing some shared data and final result depends on who run specifically when, are called race conditions. 5
CRITICAL REGION How do we avoid Race Condition? Mutual Exclusion: Some way of making sure that if one process is using shared variable or file, the other process will be excluded from doing same thing. The part of the program where shared memory is accessed called the critical region or critical section. 6
CRITICAL REGIONS Conditions required to avoid race condition: • • No two processes may be simultaneously inside their critical regions. No assumptions may be made about speeds or the number of CPUs. No process running outside its critical region may block other processes. No process should have to wait forever to enter its critical region.
CRITICAL REGIONS Mutual exclusion using critical regions.
MUTUAL EXCLUSION WITH BUSY WAITING Proposals for achieving mutual exclusion: • • • Disabling interrupts Lock variables Strict alternation Peterson's solution The TSL instruction Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0 -13 -6006639
DISABLING INTERRUPTS The simplest solution is to have each process disable all interrupts just after entering in critical regions and re-enable them just before leaving it. Problem: This approach is generally unattractive. Because one process do turn off the interrupts and never turned them on again. That could be the end of the system. Furthermore if the system is multi processor, with two more or CPU. Then disabling interrupts affects only one CPU. This solution is convenient for the kernel itself. Not for the user process. 10
LOCK VARIABLES Let us look for software solution. Consider having a single, Shared(lock) Variable initially 0. When process want to enter in critical region, it first test the lock. If the lock is 0, the process is set to 1 and enter in to critical region. If the lock is already 1 , the process is just wait until it becomes 0. Problem: Busy Waiting Same problem like printer spooler 11
STRICT ALTERNATION A proposed solution to the critical region problem. (a) Process 0. (b) Process 1. In both cases, be sure to note the semicolons terminating the while statements.
Peterson's Solution Problem: Busy Waiting Waste CPU time
The TSL Instruction Entering and leaving a critical region using the TSL instruction.
SLEEP & WAKE UP Peterson and TSL solution are correct, but both have the defect of requiring busy waiting. Sleep & Wakeup. Sleep is the system call that cause the caller to block, that is be suspended until another process wakes it up. The wake up call has one parameter the process to awakened. 15
PRODUCER CONSUMER PROBLEM. It is also known as bounded buffer problem. Two process share a common , fixed size buffer. The producer put the information in to buffer. Consumer takes it out. Trouble arise when the producer want to put a new item in the buffer, but is already full. The solution is for the producer go to sleep, to be awakened when the consumer has removed one or more items. Similarly if the consumer wants to remove item and see that buffer is empty, it goes to sleep until the producer put the something in the buffer and wake it up. Buffer P C 16
PRODUCER CONSUMER PROBLEM. (CONT. ) To keep track of the umber of item, we will need a variable count. Maximum number of item the buffer can hold is N. First producer code test the count. If count=N then goto sleep otherwise add an item. And increment the count. Consumer code is similar. First it test the count. If count =0, then go to sleep. Otherwise it remove item and decrement the count. 17
The Producer-Consumer Problem . . .
WAKE UP LOST PROBLEM Solution: Wake up waiting bit When wake up is sent to process that is still awake, this bit is set. Later when process tries to go to sleep, If the wakeup bit is on, it will turned off. 19
SEMAPHORES Semaphore is a protected variable that provides a simple but useful abstraction for controlling access by Multiple process to a common resource. Semaphore is as record how many units of particular resource are available. Semaphore a useful tool in the prevention of race condition and deadlocks. Semaphore which allow an arbitrary resource count are called counting semaphores. Semaphore which are restricted to the values 0 and 1 are called binary semaphores 20
SEMAPHORES(CONT. ) Counting semaphore are equipped with two operation. Here two operations. Down and up. The value of the semaphore S is the number of units of the resource that are currently available. Down(P) operation on semaphore check to see if value is greater then 0, if so, it decrement the value and just continue. If the value is 0, the process is put to sleep. This operation is indivisible atomic action. The up(V) operation increment the value of semaphore. 21
22
SEMAPHORES(CONT. ) Semaphore solve the Lost wakeup Problem. This solution uses three semaphores. One called full for counting the number of the slots that are full. One called empty for counting the number of slots that are empty. One called mutex to make sure the producer and consumer do not access the buffer at the same time. Full is initially 0. Empty is initially equal to number of slot in buffer. Mutex is initially 1. 23
The producer-consumer problem using semaphores . . .
MUTEXES When the semaphore’s ability to count is not needed, a simplified version of the semaphores is called the MUTEX. Mutex are good only for mutual exclusion to shared some resources. This is specially useful in thread packages that are implemented entirely in user space. A mutex is variable that can be one of two states. Unlocked or Locked With 0 meaning unlocked and all other value meaning locked. Thread_yield is thread call which allow thread to voluntary give the CPU and to let another thread run. 25
Mutexes Implementation of mutex lock and mutex unlock.
MONITORS Hoare and brinch hansen proposed higher level synchronization primitive called Monitors. A monitor is collection of procedures, variables and data structures that group together in a special kind of package. Process may call the monitor procedure but they can not directly access the internal data structure of procedure in monitor. Monitor have an important property to achieved mutual exclusion. Only one process can active in monitor at any instant. It easy to put all the test of buffer full and buffer empty in monitor procedure. But how should producer block when it find the buffer full. This solution lies in condition variable. 27
SYNCHRONIZATION Synchronisation achieved by condition variables within a monitor only accessible by the monitor. Monitor Functions: wait(c): it does wait on some condition variable c and this action cause the calling process to block. signal(c) : wake up its sleeping partner by doing a signal on condition variable.
CHIEF CHARACTERISTICS Local data variables are accessible only by the monitor Process enters monitor by invoking one of its procedures Only one process may be executing in the monitor at a time Implemented in a number of programming languages, including Pascal, Pascal-Plus, Java
Monitors
An outline of the producer-consumer problem with monitors.
PROCESS INTERACTION When processes interact with one another, two fundamental requirements must be satisfied: synchronization and communication. Message Passing is one solution to the second requirement Added bonus: It works with shared memory and with distributed systems
MESSAGE PASSING The actual function of message passing is normally provided in the form of a pair of primitives: send (destination, message) receive (source, message)
DESIGN ISSUE FOR MESSAGE PASSING Message can be lost by network. To guard again lost message the receiver can send the acknowledgement to the sender. Acknowledgement can be lost in network, then sender again retransmit the message. So the receiver get it twice. It is very difficult for receiver to distinguish between old message and new message. If receiver get the same sequence number as the previous message then ignore the new message. Authentication is also an issue in message system. One design issue is that when client and server both are on same machine. Message size, how process are named? 34
DIRECT ADDRESSING Send primitive includes a specific identifier of the destination process Receive primitive could know ahead of time which process a message is expected Receive primitive could use source parameter to return a value when the receive operation has been performed
INDIRECT ADDRESSING Messages are sent to a shared data structure consisting of queues Queues are called mailboxes One process sends a message to the mailbox and the other process picks up the message from the mailbox
GENERAL MESSAGE FORMAT
PRODUCER CONSUMER PROBLEM WITH MESSAGE PASSING We assume that all message are the same size. Message sent but yet not received are buffered automatically by the OS. In this N message is used. It means N slots in shared memory buffer. Consumer start by sending N empty message to the producer. When producer has an item to give the consumer, it takes an empty message and send back a full one. If producer works faster than, it block for some time. 38
Producer-Consumer Problem with Message Passing . . .
Producer-Consumer Problem with Message Passing. . .
DINING PHILOSOPHERS PROBLEM: SCENARIO
SOLUTION This solution required the five statement following the call to think by a Binary semaphores. Before starting acquiring forks , a philosopher would do down on mutex. After replacing forks , she would up on a mutex. From theoretically point it is true. But practically it is wrong. It use an array state to keep track of whether a philosopher is eating, thinking, or hungry. A philosopher move only eating state if neither neighbors is eating. Philosopher I’s neighbors are defined by the macro LEFT and RIGHT. If I is 2, LEFT is 1 and RIGHT is 3. The program use an array of semaphores. One per philosopher. 42
Dining Philosophers Problem . . A solution to the dining philosophers problem.
Dining Philosophers Problem. . .
READERS/WRITERS PROBLEM A data area is shared among many processes Some processes only read the data area, some only write to the area Conditions to satisfy: 1. 2. 3. Multiple readers may read the file at once. Only one writer at a time may write If a writer is writing to the file, no reader may read it.
The Readers and Writers Problem A solution to the readers and writers problem.
The Readers and Writers Problem. . A solution to the readers and writers problem.
THE SLEEPING BARBER PROBLEM 48
THE SLEEPING BARBER PROBLEM 49 Solution to sleeping barber problem.
- Slides: 49