<< Chapter < Page Chapter >> Page >

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.

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Operating systems. OpenStax CNX. Aug 13, 2009 Download for free at http://cnx.org/content/col10785/1.2
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Operating systems' conversation and receive update notifications?

Ask