* On the duality of operating system structures
* Authors: Hugh C. Lauer, Roger M. Needham
* Field: OS/Concurrency
* Reference: Operating Systems Review, Vol. 13, No. 2, April 1979

* Theme: Message passing and procedure oriented systems are
essentially equivalent to each other in power, performance, and
structure.  The decision of which to use in designing a system should
therefore be based on "second order" factors, especially the ease of
implementation of the synchronization primitives on a particular
architecture.

Message Passing Style: Message passing has large, static processes
which communicate by passing messages.  The messages are stored in
queues and handled serially.  Pre-emption occurs when a higher
priority message arrives for a process which is listening for that
type of message.  Virtual memories are placed in correspondence with
processes.  Processes are associated with system resources.  Messages
are like "tokens" which delimit when a process can access and modify
certain data structures.  Channels = link to other processes, Ports =
queues for arriving messages.

Procedure Oriented Style: Procedure oriented systems are basically
multi-threaded servers.  Shared global data structures are protected
by locks, monitors, or other synchronization method.  Queues remember
all processes waiting for locks.  System resources are encoded in data
structures, and processes wander around the whole system.

* Implementation: Canonical models of the two styles are presented and
then the correspondence between the parts of each style are equated.
Some interesting correspondences:

  Message            Procedure
  ----------------   ---------
  Processes          Monitors
  Message Channels   External procedure identifiers
  Send/Recv immed    Procedure call
  Send/Recv+delay    Fork/join
  Main loop switch   Monitor lock + "extern" identifier
  Selective waiting  Condition vars, Wait & Signal

Selective waiting = waiting for a message on a particular channel.

* Examples: CAP system was converted from message passing to procedure
oriented.  Claim architecture prompted a serendipitous design that
lent itself to easy conversion.

* Problems: Authors claim difficulty of converting most real systems
caused by the "underlying addressing issues, use of global data, and
styles of communication" -- but weren't these the same issues they are
trying to tell us can be easily converted b/t the two styles?

* Quote: The arguments about processes and synchronization which are
often found in the corridors of organizations actively designing a new
system take on a decidedly non-technical tone.

* Take: A very insightful piece which deserves a re-reading.  In
retrospect, it makes sense -- to the hardware the two styles look the
same, as the probably must, because the effect is always to manage
system resources in an efficient way.  The utility of each model is in
the way it structures how we think about synchronization, sharing, and
managing resources.