...cont Message Passing
-2 system calls: send() and receive()
-embody data transfer AND synchronization
-Note: the programmer is not worried about “over-producing” things
-What if the kernel gets “u over-whemled”?
-a kernel could block or not schedule a producer to run!
With Flow Control - controlling the “flow” of data
Producer: - i need to receive a “ready” message by the consumer so I can start producing!
-then, a producer can produce up to N message
-then, the producer stops
-the Consumer “consumes” the item, and sends a “ready” message to the Producer
-send the “ready” message FIRST before “consuming” the item
1. Who should messages be “addressed” to?
-add ports: (‘mailbox”) - send the item to an address for which the consumer then “picks” up the
-everyone “agrees” to the port #s given
2. How to make a process receive from “anyone”?
-indicator - I am willing to take anything from anybody
-returns a pid or port # so they can send a response back
3. Kernel buffering: “outstanding” messages (messages produced, but NOT received)
-”block” a process from producing more messages
-For example, give every process a “fixed”, pre-allocated amount of memory
-if a process uses up all that memory, then block it!
4. Good paradigm for IPC networks - no “shared” memory! (“self-contained”)
5. “Safer” than shared memory paradigms
Deadlock - set of processes are permanently blocked (unable to run!)
-unblocking one of them relies on another actually running
- A holding resource X, waiting for resource Y
- B holding resource Y, waiting for resource X
Four Conditions for Deadlock
1. Mutual Exclusion - ONLY one process may use a resource at a time (ie critical section)
2. Hold-and-Wait - process “holds” resource while “waiting” for another
3. No preemption - can’t “take” away resource from a process
4. Circular Wait - the waiting processes form a “cycle”