Consider the inter process communication scheme where mailboxes are used. (a)…

Inter-Process Communication (IPC) using Mailboxes

A mailbox is an object into which messages can be placed by processes and from which messages can be removed.

(a) Waiting for two messages (One from A AND one from B)

To receive messages from both, Process P must execute two blocking receive operations. Blocking means the process will stop and wait until the message arrives.

• Sequence: 1. receive(A, message); 2. receive(B, message);

• Logic: The order does not matter (A then B, or B then A). Process P will stay in a "waiting state" until both mailboxes have delivered a message. Only then will P move to the next instruction.

(b) Waiting for one message (From A OR B or both)

If P waits for either A or B, a simple receive(A) won't work because if a message arrives in B first, the process will still be stuck waiting for A.

• Scheme (Polling/Non-blocking): Process P should use a "polling" or "select" mechanism.

  C

  while (true) {
      if (Mailbox A has a message) { receive(A); break; }
      if (Mailbox B has a message) { receive(B); break; }
  }
  

• Logic: P checks both mailboxes repeatedly. As soon as it finds a message in either one, it takes the message and continues its work.

(c) Waiting until a Mailbox is Empty

Standard IPC systems usually don't have a direct "Wait-until-Empty" command. They are designed to wait for data, not the absence of data.

• Proposed Scheme: We can use a Counter or Semaphore.

  1. Every time a message is sent, the counter increases.

  2. Every time a message is received, the counter decreases.

  3. Process P will "Wait" or "Poll" until the Counter == 0.

• Conclusion: Without a counter or a status flag, a process cannot "block" on an empty mailbox naturally. It would have to keep checking (Busy Waiting), which is not efficient for the CPU.