On the Duality of Operating System Structures

1
On the Duality of Operating System Structures

Hugh C. Lauer Xerox Corporation Paolo Alto,
California
Roger M. Needham Cambridge University Cambridge,
England
Presenter M. Argun Alparslan
2
Outline

• Motivation
• Two Models
• Duality Mapping
• Performance Issues
• Concluding Remarks

3
Motivation

• Operating Systems fall into two main categories
  depending upon notion of process, IPC and
  synchronization
• Message Oriented Systems
• Procedure Oriented Systems
• Are these two types duals of each other
• Is there a mapping between two?
• Do their performance differ?

4
Message Oriented Systems

• The number of processes and the connections
  between them stay relatively static.
  Communication among processes are done via
  messages (or events).
• Each process acts in a relatively static context.
  Processes rarely cross protection boundaries and
  they rarely share data.(Not necessarily nowadays)

5
Message Oriented Systems

• Synchronization via message queues attached to
  processes. (e.g. SEDA)
• Priorities are set statically in the system
  design
• Processes act upon very small number of messages
  at a time
• Data structures are manipulated via references in
  the messages. No process accesses the data unless
  it is currently processing a message referring to
  it.

6
Messages

• A message is a data structure used for sending
  information from a process to another (similar
  to MPI)
• SendMessagemessageChannel, messageBody returns
  messageId --
• AwaitReplymessageld returns messageBody --
• WaitForMessageset of messagePort returns
  messageBody, messageld,messagePort
• SendReplymessageld, messageBody

7
Resource Manager

• begin m messageBody
• i messageld
• p portld
• s set ofportld
• ... --local data and state information for this
  process
• initialize
• do forever
• m, i, p - WaitForMessages
• case p of
• port1 gt... --algorithm for poR1
• port2 gt...
• if resourceExhausted then
• s s - port2
• SendReplyi, reply
• . . . --algorithm for port2
• portk gt.
• s s port2
• ... --algorithm for portk
• endcase

8
Procedure-Oriented System

• Protection and addressing based mechanism with
  efficient procedure call facilities.
• Synchronization is carried out via locks,
  semaphores, monitors.
• Process creation overhead is low hence large
  number of processes
• A process has only one job and wanders all over
  the system, little or no messaging.
• System resources tend to be encoded in global
  data structures

9
Procedure Oriented System

• Synchronous calls are made via procedures whereas
  asynchronous calls are via
• processIdlt-Fork procedureNameparameterList
• resultList lt-Join processId
• Modules as primitive unit of compilation
• Monitors with condtion variablesHoare are used
  for resource management
• Wait conditionVariable
• Signal conditionVariable

10
Resource Manager

• ResourceManager MONITOR
• C CONDITION
• resourceExhausted BOOLEAN
• .. --global data and state information for this
  process
• procl ENTRY PROCEDURE. .
• .. --algorithm for procl
• proc2 ENTRY PROCEDURE... RETURNS . .
• BEGIN
• IF resou rceExhausted THEN WAIT C
• ...
• RETURN results
• ...
• END --algorithm for proc2
• ...
• procL ENTRY PROCEDURE...
• BEGIN
• ...
• resourceExhausted FALSE
• SIGNAL C

11
Duality
12
Duality Mapping

• Procedure-oriented system
• Monitors
• ENTRY procedure names
• Simple procedure names
• Procedure call/return
• Simple
• Fork/Join
• Return (from Procedure)
• Wait for lock, condition var
• ENTRY procedures
• Signal, Wait condition variable

• Message-oriented system
• Processes
• Message Channel IDs
• Port numbers
• SndMsgAWaitReply
• Immediate
• Delayed
• SendReply
• WaitForMsg
• Arms of case
• Selective waiting for messages

13
Performance Comparison

• Three components are compared
• Execution times of the programs Same number of
  operations in the core algorithms
• Computational overhead of the primitive system
  operations they call, same complexity
• SendFork (allocate, queue, context switch)
• Process switching, VM access can be done equally
  efficient
• Scheduling, dispatching, preemption equally
  efficient
• Can use same disciplines
• Queuing and waiting times can be made identical
  since the used scheduling policies are same

14
Conclusion

• Choosing which model to adopt relies on 2nd-order
  factors
• 0th order similar program structure,
  performance of client programs
• 1st order similar computational complexity
• 2nd order machine architecture features,
  programming environment set a priori, emotions
  so will drive decisions
• Can drive decision closure on process structure
  and synchronization using these 2nd order factors

15
Critique

• No rigorous proofs
• Mostly empirical
• Performance arguments hard to believe
• Manual Stack ripping and stack memory
• Events use cooperative scheduling
• Event systems use shared memory

16
Questions?
17
Resources

• "Monitors An operating system structuring
  concept.", by C. Hoare, Communications of the
  ACM, No. 17, 1974, 549-557.
• "SEDA an architecture for well-conditioned,
  scalable internet services", by M. Welsh, D.
  Culler, E. Brewer, Proceedings of the eighteenth
  ACM symposium on Operating systems principles,
  2001, 230243.
• "Why Events Are a Bad Idea for High-Concurrency
  Servers", by R. Behren, J. Condit, E. Brewer,
  Proceedings of HotOS III the Ninth Workshop on
  Hot Topics in Operating Systems, 2003, 19-24.
• A Language-based Approach to Unifying Events and
  Threads by Li, Zdancewic, 2006
• Presentation by David Allen from PDX

18
Discussion