Phones OFF Please

1. Phones OFF Please Inter-Process Communication (IPC) Parminder Singh Kang Home: www.cse.dmu.ac.uk/~pkang Email: pkang@dmu.ac.uk

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

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

4. Producer algorithm: loop if freeslots > 0 then add an item decrease freeslots by 1 endloop Consumer algorithm: loop if freeslots < BUFSIZE then remove an item increase freeslots by 1 endloop

5. 2 Peer to Peer model and client/server model • Peer to Peer • Process A Process B • send message  rec message • rec message  send message • Client/Server • Client Server • loop • send message  wait for message • rec 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, …

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

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

8. 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 :-

9. Process A Process B • LOOP LOOP • IF ItIsFree then IF ItIsFree then • ItIsFree := FALSE ItIsFree := FALSE • put data in buffer take data from buffer • ItIsFree := TRUE ItIsFree := TRUE • END END • END 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

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

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

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

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

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

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

16. 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;

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

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

20. 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])| | • ----------- ------------

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

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

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

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

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

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

27. 6.3 Synchronization and buffering • Synchronization • blocking send • non blocking send • blocking receive • non blocking receive • Buffering • zero capacity • finite capacity • infinite capacity