Phones OFF Please

Inter-Process Communication (IPC)

Parminder Singh Kang

Home: www.cse.dmu.ac.uk/~pkang

Email: pkang@dmu.ac.uk

1. IPC

• Most modern operating systems are multi-tasking (e.g. Unix, O/S2, Linux, Windows Nt, Windows 95).

• Distributed environment, client/server (processes could be on different CPU's.)

• IPC; a mechanism to allow processes to communicate and to synchronize • their actions without sharing same address space. distributed computing

environment; where processes may reside on different machines over network.

• Often processes want to communicate. We can split them into two types:-

  Uniprocessor IPC multiprocessor IPC / \

Distributed systems Multi-CPU systems (Networked) (Shared bus) 

• The O/S provides most mechanisms, but some are language dependent

• Usually processes form a client/server or consumer/producer relationship.

2 Producer/Consumer relationship

• One process generates data, the other receives it, i.e. producer/consumer

• Synchronization, e.g. we have a loop where

• Producer generates some data• Consumer reads the data

• Condition;

• Consumer needs to know when data has been produced.• Producer needs to know when it can produce more data.

• Communication is based on handshaking (as in hardware and I/O devices)

• Producer/Consumer process is

Producer Buffer Consumer

Need a variable – freeslots –indicates if anything is in buffer 

Producer algorithm:

loopif freeslots > 0 then

add an itemdecrease freeslots by 1

endloop Consumer algorithm:

loopif freeslots < BUFSIZE then

remove an itemincrease freeslots by 1

endloop

2 Peer to Peer model and client/server model

• Peer to Peer 

Process A Process B

send message rec messagerec message send message

 • Client/Server

 Client Server

loopsend message wait for messagerec message send message

end loop

Note server runs continuously in a loop. Client runs then finishes.  

• UNIX servers called daemons, e.g.

• Clients telnet, ftp …• Sever daemons are telnetd, ftpd, …

3 Overview of I.P.C. Mechanisms

• Shared memory:

• only one process can access memory at a time (mutual exclusion). We can use;

• Signals - unreliable. Signals aren't queued, so some can get lost.

• Semaphores - low level. Make a mistake and everything goes to sleep.

• Event-counters - simpler than semaphores. Not very common but not guaranteed.

• Message passing

• Pipes or unbound sockets - only used by related processes. Easy to use. Synchronisation controlled by O/S

• Sockets - Similar to pipes/file access. Can be used across network. Different varieties - guaranteed delivery (virtual circuits), unreliable (datagram)

• Rendezvous - similar to pipes/sockets but no buffering. Used in Occam and Ada.

• Shared files - similar to shared memory in virtual memory systems, since the file

can be memory mapped. Can include record locking to enable synchronising.

• Named pipes - similar to pipes, but used by unrelated processes.

• Message passing. Similar to pipes, sockets, etc, but message boundaries preserved.

• Remote Procedure Call (RPC)

4. Shared Memory

• The most efficient IPC mechanism is probably shared memory. .------------. .------------. .------------.

| | | Shared | | | | Process A |-------->| Memory |----------> | Process B |

| | | | | | ------------ ------------ ------------

 • If we allow uncontrolled access we can get race conditions –

• Results depend on which process accesses memory.

• For example, consider process A is a producer, and process B is a consumer.

• Process A is putting data into a buffer (the shared memory), process B is removing it.

•To control access we have a shared variable called ItIsFree, which is true

• when no process is accessing the buffer. The two processes might look like :-

Process A Process B

LOOP LOOP IF ItIsFree then IF ItIsFree then

ItIsFree := FALSE ItIsFree := FALSEput data in buffer take data from bufferItIsFree := TRUE ItIsFree := TRUE

END ENDEND END

 • Problems can occur if testing and setting ItIsFree is not a single operation.

Process A Process B |

does test - ItIsFree is TRUE does test - ItIsFree is TRUE set ItIsFree FALSE set ItIsFree FALSE

now both accessing the buffer at the same time 

Note: The section of code which accesses the shared memory is called the critical section. To ensure race conditions cannot occur we need mutual exclusion - only one process is in its critical section at a time.

• Avoidance:  

• No two processes simultaneously in their critical sections.

• No assumption should be made about speed or number of CPU's.

• Processes outside their critical region should not be able to block other processes.

• No process should have to wait forever to enter its critical section.

4.1 Access control - TAS instruction

 

• To control access we want an indivisible instruction which can test and set a variable in one operation.

• 

label: TAS variable ; test the access variable

BNE label ; wait for zero

:

critical section of code using shared region

:

CLR.B variable ; set to 0 to allow access

 

This is of little use since it uses busy-waiting (the TAS loop) and is a waste of CPU time.

4.2 Access control - Sleep and Wakeup 

• Process should sleep until the region is clear, then be woken up.

• system calls:

• sleep send process to sleep• wakeup wake process up. (i.e. make it ready to run)

• The mechanism;

• producer has produced some output, wakes the consumer and goes to sleep itself.

• When the consumer has consumed the input it wakes the producer and sends itself to sleep. So the two processes alternate and wake each other.

• What if signal Lost?

• the producer reads the flag and finds it zero

• but before it can go to sleep the consumer is scheduled

• the consumer sends a wakeup, which gets lost, since nothing is asleep yet

• the consumer then goes to sleep, waiting for the producer to wake it

• the producer resumes and completes its sleep operation.

• Both then sleep forever.

• The solution is to store the wakeups - we then have the semaphore.

4.3 Access control - Semaphores 

• A semaphore is a cardinal variable, with an associated list of sleeping processes.

• plus two atomic operations, which can be performed on it.

•The two operations are DOWN(s) and UP(s) both will be system calls •(s is the semaphore. Definition:-

DOWN(s): If s = 0 then send process to sleep Else decrement s End

 UP(s): If any processes asleep on s then wake one (i.e. make it ready to run)

Else increment s End 

• If s only takes the values 0 and 1 it is a binary semaphore, otherwise it is a general semaphore.

•Semaphores are only used to enable processes to synchronise themselves.

•i.e. to ensure only one process enters a critical region at a time.

• In typical use each process will have the following:

DOWN(s) : critical section : UP(s)

 • Initially s is set to 1.

• If process A runs first and does a DOWN, Set S to 0.

• Once A has completed the DOWN it can be interrupted, even if it is still in its critical section. Suppose this happens and process B is set running.

• If it does the DOWN it will be sent to sleep. Process A will eventually be set running again and will do an UP on exiting its critical region.

•This will wake up B. Note we can have more than two processes.

4.4 Access control - event counters 

• Like the semaphore an event counter is a cardinal variable with an associated list of sleeping processes.

• Apart from initialising the are 3 operations which can be performed;

READ(e) read the value of 'e‘ ADVANCE(e) increment 'e‘ AWAIT(e,v) wait until 'e' has a value of 'v' or more.

 • Like semaphores they are atomic system calls.

• For example in the producer/consumer situation, we could have: 

ine = 0; oute = 1; pseq = 0; cseq = 0;

 

• then the producer would be  LOOP : produce an item inc(pseq) AWAIT(oute, pseq) put item in the buffer ADVANCE(ine) : END and the consumer would be  LOOP : Inc(cseq) AWAIT(ine, cseq) get item from buffer ADVANCE(oute) : END

5 UNIX IPC

5.1 Pipes

• Unix originally just had the pipe as the IPC mechanism.

• Pipe is a convenient high level mechanism; created with system call,

int pipe(int filedes[2]);

• pipe creates a pair of file descriptors, pointing to a pipe i-node

• places them in the array pointed to by filedes.

• filedes[0] is for reading

• filedes[1] is for writing.

• On success, zero is returned, on error, -1 is

#include <unistd.h> int fd[2], rval; if ((rval = pipe(fd)) < 0) cout << " error creating pupe";

• Performing Read and Write:

• Read; block an empty pipe until some data is put into the pipe.

• Process fills a pipe it blocks until some bytes are removed from the pipe.

• The read command will return with zero bytes when end of file is met,

• When the pipe has no writing processes left.  A single pipe can be used to send information one way or the other, i.e.:   ----------- ------------| | write(p[1]) read(p[0]) | || |======>===========--==========>======= | || parent| || | child || |======<===========__==========<======= | || | read(p[0]) write(p[1])| | ----------- ------------

• Either the child or parent writes; not both at the same time.

• To have simultaneous two way communication you can have two pipes,

• say p and q. It usual to close the ends of the pipe down you don't want,

• e.g. after the fork command the parent can close q[0] and p[1],

• Child can close q[1] and p[0]. Thus the parent writes into q and reads from p, and the child writes to p and reads from q.

6. Message Passing System

• Communication among user processes is accomplished by passing messages.

• At lease two operations are required;

• send (Message)

• receive (Message)

• Messages can be of variable or fixed size.

• Fixed size; system level implementation is easy but programming task is difficult.

• Variable size; Complex system level implementation but programming is much simpler.

• Several Methods for logical implementation

• Direct or indirect communication.

• Symmetric or Asymmetric communication.

• Automatic or Explicit buffering.

• Send by Copy or Send by Reference.

• Fixed size or Variable size messages.

6.1 Direct communication:

Direct Communication

Symmetric naming

• sender and receiver have name of each process.

• send(p,message) -> sends message to p

• receive(q,message)-> receive message from q

Asymmetric naming

• only sender names recipient; receiver uses id instead of name.

• send (p,message) send message to p

• receive(id,message) receive message from any process.

• conditions;

• automatic link should be established between two processes.

• a link should be associated only with two processes.

• exactly one link should exists between pair of processes

6.2 Indirect communication:

• Messages are sent or received from mailboxes or port.

• Implementation;

• create new mailbox.• send and receive message through mail box.• delete mailbox.

• send(A,message) send message to mailbox A

• receive(a,message) receive message from mailbox A

• Communication link properties;

• Link is only established if both processes r member of same mailbox.

• Link can be associated with more than one processes.

• A number of different links can be exists between each pair of communicating process.

6.3 Synchronization and buffering

• Synchronization

• blocking send

• non blocking send

• blocking receive

• non blocking receive

• Buffering

• zero capacity

• finite capacity

• infinite capacity