Interprocess Communication

Question 1

What are the two fundamental models of IPC?

Answer 1

1. Shared memory: map the same physical region in the AS of multiple processes
2. Message passing: explicitly use syscalls to pass data between processes

Question 2

Reasons for cooperating processes

Answer 2

• information sharing
• computation speed-up
• modularity

Question 3

Direct vs. indirect messages

Answer 3

• processes name each other explicitly when exchanging direct messages; send(P, message), receive(Q, message)
• indirect messages can be sent to and received from mailboxes. each mailbox has a unique ID
• first communicating process creates mailbox, last destroys mailbox
• processes can communicate only if they share a mailbox

Question 4

Messages are queued using different capacities, enumerate them

Answer 4

1. Zero capacity - 0 messages/no queueing
   - sender must wait for receiver (rendezvous)
   - message is transferred as soon as receiver becomes available => no latency/no jitter
2. Bounded - finite length of messages
   - sender can send before receiver waits for messages
   - sender can send while receiver still processes previous message => variable latency between send and receive
   - sender must wait if link full
3. Unbounded
   - sender never waits
   - memory may overflow

Question 5

Why is shared memory often more difficult to use than message passing?

Answer 5

Shared memory requires synchronization to avoid race conditions and to maintain consistency.

Question 6

What is a mailbox and how are they uniquely identified in Linux?

Answer 6

Mailbox: Indirect messaging approach; sender sends a message to a mailbox instead of directly to the receiver.

In Linux: file name (POSIX)

Question 7

Why timeouts for IPC operations

Answer 7

prevent malicious or buggy clients from taking up resources indefinitely

Question 8

Where can the buffer for asynchronous send operation be stored? (advantages & disadvantages)

Answer 8

1. receiver AS:
   - doesn’t scale well, because receiver buffer needs to be big enough for all senders
2. kernel:
   - security issues; flooding the kernel with requests and DoS attacks
3. sender AS:
   best option
   + sender needs to allocate a buffer anyway
   + scales well
   - needs notification when transfer is ready (for freeing)
   - potentially keep the buffer for a long time or make a copy of it

Question 9

In a synchronous system, it might be a good idea to have atomic send-and-receive operation. Give an example

Answer 9

1. client invokes action X on the server
2. server receives X and executes it
3. server sends reply to client
4. client receives reply
5. server frees buffer

to protect from malicious clients, server needs a timeout for 4. An atomic send-and-receive would however guarantee 4. and 5., so there would be no need for timeouts

Question 10

How to emulate asynchronous IPC with synchronous calls?

Answer 10

• busy-waiting loop until message is sent or received
• but we don’t know whether the receiver got the message
• add a mini-protocol and wait for ACK message from the reciever

Question 11

How to emulate synchronous IPC with asynchronous calls?

Answer 11

start a new thread per request which blocks until a reply is there

Question 12

Can programmers expect sequential memory consistency for their multi-threaded programs?

Answer 12

No. Both the compiler and the CPU may reorder load and store operations to improve performance. Consequently, synchronization is usually necessary when accessing the same memory location concurrently.