What are the two fundamental models of IPC?
- Shared memory: map the same physical region in the AS of multiple processes
- Message passing: explicitly use syscalls to pass data between processes
Reasons for cooperating processes
- information sharing
- computation speed-up
- modularity
Direct vs. indirect messages
- 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
Messages are queued using different capacities, enumerate them
- 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 - 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 - Unbounded
- sender never waits
- memory may overflow
Why is shared memory often more difficult to use than message passing?
Shared memory requires synchronization to avoid race conditions and to maintain consistency.
What is a mailbox and how are they uniquely identified in Linux?
Mailbox: Indirect messaging approach; sender sends a message to a mailbox instead of directly to the receiver.
In Linux: file name (POSIX)
Why timeouts for IPC operations
prevent malicious or buggy clients from taking up resources indefinitely
Where can the buffer for asynchronous send operation be stored? (advantages & disadvantages)
- receiver AS:
- doesn’t scale well, because receiver buffer needs to be big enough for all senders - kernel:
- security issues; flooding the kernel with requests and DoS attacks - 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
In a synchronous system, it might be a good idea to have atomic send-and-receive operation. Give an example
- client invokes action X on the server
- server receives X and executes it
- server sends reply to client
- client receives reply
- 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
How to emulate asynchronous IPC with synchronous calls?
- 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
How to emulate synchronous IPC with asynchronous calls?
start a new thread per request which blocks until a reply is there
Can programmers expect sequential memory consistency for their multi-threaded programs?
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.
