Inter-Process Communications (IPC)

1. Inter-Process Communications (IPC) Fred Kuhns CS422S

2. Cooperating Processes • Independent process cannot affect or be affected by the execution of another process. • Cooperating process can affect or be affected by the execution of another process • Advantages of process cooperation • Information sharing • Computation speed-up • Modularity • Convenience

3. Producer-Consumer Problem • Paradigm for cooperating processes, producer process produces information that is consumed by a consumer process. • unbounded-buffer places no practical limit on the size of the buffer. • bounded-buffer assumes that there is a fixed buffer size.

4. Bounded-Buffer – Shared-Memory • Shared data #define BUFFER_SIZE 10 Typedef struct { . . . } item; item buffer[BUFFER_SIZE]; int in = 0; int out = 0; • Solution is correct, but can only use BUFFER_SIZE-1 elements

5. Bounded-Buffer – Producer Process item nextProduced; while (1) { while (((in + 1) % BUFFER_SIZE) == out) ; /* do nothing */ buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; }

6. Bounded-Buffer – Consumer Process item nextConsumed; while (1) { while (in == out) ; /* do nothing */ nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; }

7. Purposes for IPC • Data Transfer • Sharing Data • Event notification • Resource Sharing and Synchronization • Process Control

8. IPC Mechanisms • Mechanisms used for communication and synchronization • Message Passing <Focus of Lecture> • message passing interfaces, mailboxes and message queues • sockets, STREAMS, pipes • Shared Memory (Non-message passing systems) • Synchronization • Debugging • Event Notification - signals

9. Message Passing • In a Message system there are no shared variables. IPC facility provides two operations: • send(message) – size fixed or variable • receive(message) • If P and Q wish to communicate, they need to: • establish a communicationlink • exchange messages via send and receive • Implementation of communication link • physical (e.g., shared memory, hardware bus) • logical (e.g., logical properties)

10. Implementation Questions • How are links established? • Can a link be associated with more than two processes? • How many links can there be between every pair of communicating processes? • What is the capacity of a link? • Is the size of a message that the link can accommodate fixed or variable? • Is a link unidirectional or bi-directional?

11. Direct Communication • Processes must name each other explicitly: • Symmetric Addressing • send (P, message) – send to process P • receive(Q, message) – receive from Q • Asymmetric Addressing • send (P, message) – send to process P • receive(id, message) – rx from any; system sets id = sender • Properties of communication link • Links are established automatically • A link is associated with exactly one pair of communicating processes. • exactly one link between each pair. • usually bi-directional.

12. Indirect Communication • Messages are directed and received from mailboxes (also referred to as ports). • Each mailbox has a unique id. • Processes can communicate only if they share a mailbox. • Properties of communication link • Link established only if processes share a common mailbox • A link may be associated with many processes. • Each pair of processes may share several communication links. • Link may be unidirectional or bi-directional.

13. Indirect Communication • Operations: • create a new mailbox • send and receive messages through mailbox • destroy a mailbox • Primitives: • send(A, message) – send a message to mailbox A • receive(A, message) – receive a message from mailbox A

14. Indirect Communication • Mailbox sharing: • P1, P2, andP3 share mailbox A. • P1, sends; P2andP3 receive. • Who gets the message? • Solutions • Allow a link to be associated with at most two processes. • Allow only one process at a time to execute a receive operation. • Allow the system to select arbitrarily the receiver. Sender is notified who the receiver was

15. Synchronization • Message passing may be either blocking or non-blocking. • Blocking is considered synchronous • Non-blocking is considered asynchronous • send and receive primitives may be either blocking or non-blocking.

16. Buffering • Queue of messages attached to the link; implemented in one of three ways. 1. Zero capacity – 0 messagesSender must wait for receiver (rendezvous). 2. Bounded capacity – finite length of n messagesSender must wait if link full. 3. Unbounded capacity – infinite length Sender never waits.

17. Client-Server Communication • Sockets • Remote Procedure Calls • Remote Method Invocation (Java)

18. Sockets • A socket is defined as an endpoint for communication. • Socket protocol specific address: • Internet domain (INET) - concatenation of an IP address and port • UNIX domain - pathnames within the normal filesystem. • The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8 • Communication consists between a pair of sockets.

19. INET Socket Communication

20. Remote Procedure Calls (RPC) • Remote procedure call abstracts procedure calls between processes on networked systems. • Stubs – client-side proxy for the actual procedure on the server. • The client-side stub locates the server and marshalls the parameters. • The server-side stub receives this message, unpacks the marshalled parameters, and performs the procedure on the server.

21. Execution of RPC

22. Remote Method Invocation (RMI) • Remote Method Invocation is a Java mechanism similar to RPCs. • RMI allows a Java program on one machine to invoke a method on a remote object.

23. Marshalling Parameters

24. Error Recovery • Process terminates • Lost messages • Scrambled Messages

25. UNIX Examples • Basic UNIX InterProcess Communication Mechanisms. • Universal IPC mechanisms • S5R4 mechanisms • Mach • Synchronization primitives will be covered in subsequent lectures

26. Conventional View Protection domains - (virtual address space) user process 2 process n process 1 kernel How can processes communicate with each other and the kernel?

27. process 1 pipe Universal IPC Facilities handler user process 2 dbx kernel stop handle event Signals, Pipes and Process Tracing

28. Universal Facilities • Signals - asynchronous or synchronous event notification. • Pipes - unidirectional, FIFO, unstructured data stream. • Process tracing - used by debuggers to control control target process

29. Signals -Terminology • Post - The system delivers a signal to a process. • Action - defines how a signaled is handled when delivered. • Signal handler - User specified function to be invoked by the system when a specific signal occurs. • Catch - a signal handler catches a signal. • Masked - if a posted signal is masked then action is deferred until unmasked.

30. Signals - History • Unreliable Signals - Orignal System V (SVR2 and earlier) implementation. • Handlers are not persistent • recurring instances of signal are not masked, can result in race conditions. • Reliable Signals - BSD and SVR3. Fixed problems but approaches differ. • POSIX 1003.1 (POSIX.1) defined standard set of functions.

31. Signals Overview • Divided into asynchronous and synchronous • Two phases: signal generation and delivery. • SVR4 and 4.4BSD define 31 signals, original had 15. • Signal to integer mappings differ between BSD and System V implementations

32. Actions • Default actions: • terminate w/core dump, terminate no core dump, ignore signal, stop process, resume execution of process • User specified action : • Take default action, ignore signal, or catch signal with handler

33. Reliable Signals - BSD • Persistent handlers • Masking signals • user can specify mask set for each signal • current signal is masked when handler invoked • Interruptible sleeps • Restartable system calls • Allocate separate stack for handling signals • why is this important?

34. System call interface {read(), write(), sigaltstack() … } Signals - Virtual Machine Model signal handler stack Process X (Signal handles) instruction set register handles dispatch to handler kernel (restartable system calls) deliver signal I/O facilities filesystem scheduler

35. Signals - A Few Details • Any process or interrupt can post a signal • set bit in pending signal bit mask • perform default action or setup for delivery • Signal typically delivered in context of receiving process (unless it is sleeping). • Pending signals are checked before returning to user mode and just before/after certain sleep calls. • Produce core dump or invoke signal handler

36. UNIX Pipes • Unidirectional, FIFO, unstructured data stream • Fixed maximum size • Simple flow control • pipe() system call creates two file descriptors. Why? • Implemented using filesystem, sockets or STREAMS (bidirectional pipe).

37. Named Pipes • Lives in the filesystem - that is, a file is created of type S_IFIFO (use mknod() or mkfifo()) • may be accessed by unrelated processes • persistent • less secure than regular Pipes. Why?

38. Process Tracing • ptrace() • used by debuggers such as dbx and gdb. • Process must notify kernel that parent will trace it. How could we do this for an arbitrary program? • SVR4 and Solaris provides /proc

39. System V IPC Mechanisms • Semaphores • Message queues • Shared memory

40. Common Elements • Common Attributes • key - integer which identifies a resource instance • Creator - usr and grp id of resource creator • Owner - usr and grp id of owner • Permissions - FS style read/write/execute • shmget(key,…), semget(key,…), msgget(key,…) • key can be generated from a filename and integer (ftok()) or IPC_PRIVATE.

41. Common Facilities • Resources are persistent, thus must be deleted when no longer needed - must be owner, creator or superuser. • shmctl(shmid,…), semctl(semid,…), msgctl(msgid,…) • Fixed size resource table: ipc_perm structure plus type specific data • resource id = seq * table_size + index

42. Sem1 semid_ds Sem2 Sem3 Sem4 SV Semaphores Application semop(semid, sops, nsops) sem1+2, sem3+1, block until sem4 == 0 Semaphore set (semid, kernel)

43. SV Message Queues New messages msgid_ds msgrcv(msgqid, msgp, maxcnt, msgtype, flag) msgcnt, bytes maxbytes type data data data type type FIFO

44. shared memory SV Shared Memory 0x00000000 user Process 3 process 1 process 2 kernel

45. MACH IPC • Message passing fundamental mechanism • most system calls and inter-task communication • Task is created with two mailboxes: • 1) Kernel mailbox • 2) Notify mailbox • avoid unnecessary data copies • kernel must provide secure communication • transparently extensible to distributed environments. • Tightly coupled with virtual memory

46. The Basics • Message - collection of typed data • Port - protected queue of msgs • Ports also represent kernel objects • port has associated send and receive rights • only one task (owner) has receive rights for a port • multiple tasks may have send rights

47. size flags name number data Message data structures • Ordinary data - physically copied by kernel • Out-of-line memory - copy-on-write • Send or receive ports size flags type size local_port destination_port message_id data name number

48. Interface • One-way send • Blocked read - wait for unsolicited msgs • two-way asynchronous - send msg, receive reply asynchronously. • Blocking two-way - send msg and wait for reply.

49. DB server microkernel Memory mngr Task mngr I/O mngr A View Client

50. MACH Message Passing Sending Task Receiving Task Copy of data In-line (data) Copy of data copy copy copy maps Address maps Out-of-line (data) copy maps Holding map Port right (local name) Port right (local name) Pointer to port obj translate translate Received message Outgoing message Internal message