Which are more powerful, messages or monitors?
Message systems vary along several dimensions:
- Relationship between mailboxes and processes:
- One mailbox per process, use process name
in send and receive (simple but restrictive) [RC4000].
- No strict
mailbox-process association, use mailbox name (can have multiple mailboxes perprocess, can pass mailboxes from process to process, but trickier to implement)
[Unix].
- Extent of buffering:
- Buffering (more efficient for large transfers when sender
and receiver run at varying speeds).
- None -- rendezvous protocols
(simple, OK for call-return type communication, know that message was received).
- Conditional vs. unconditional ops:
- Unconditional receive: return message if mailbox is not
empty, otherwise wait until message arrives.
- Conditional receive:
return message if mailbox is not empty, otherwise return special "empty" value.
- Unconditional send: wait until mailbox has space.
- Conditional send: return "full" if no space in mailbox (message is
discarded).
What happens with rendezvous protocols and
conditional operations?
- Additional forms of waiting:
- Almost all systems allow many processes to wait on the same
mailbox at the same time. Messages get passed to processes in order.
- A few systems allow each process to wait on several mailboxes at
once. The process gets the first message to arrive on any of the mailboxes. Thisis actually quite useful (give Caesar as an example).
- Constraints on what gets passed in messages:
- None: just a stream of bytes (Unix pipes).
- Enforce message boundaries (send and receive in same chunks).
- Protected objects (e.g. a token for a mailbox).
How would the following systems fall into the above
classifications?
- Condition variables
- Unix pipes
Classical ipc problems
The dining philosophers problem
A classical problem from Dijkstra
- 5 philosophers sitting at a round table
- Each has a plate of spaghetti
- There is a fork between each two
- Need two forks to eat
What algorithm do you use for access to the shared
resource (the forks)?
- The obvious solution (pick up right; pick up left) deadlocks.
- Big lock around everything serializes.
- Good code in the book.
The purpose of mentioning the Dining Philosophers
problem without giving the solution is to give a feel of what coordinationproblems are like. The book gives others as well. We are skipping these (again
this material would be covered in a sequel course).
The readers and writers problem
- Two classes of processes.
- Readers, which can work concurrently.
- Writers,
which need exclusive access.
- Must prevent 2 writers from being concurrent.
- Must prevent a reader and a writer from being concurrent.
- Must permit readers to be concurrent when no writer is active.
- Perhaps want fairness (e.g., freedom from starvation).
- Variants
- Writer-priority readers/writers.
- Reader-priority readers/writers.
Quite useful in multiprocessor operating systems
and database systems. The “easy way out” is to treat all processes as writers inwhich case the problem reduces to mutual exclusion (P and V). The disadvantage
of the easy way out is that you give up reader concurrency. Again for moreinformation see the web page referenced above.
