1 On the Duality of Operating System Structures Hugh Lauer, Xerox Roger Needham, Cambridge University Oct 1978, reprinted April 1979 Presented by David Allen

2 Introduction Operating System Concepts  concept of process  synchronization  interprocess communication Operating Systems Categories  message-oriented system  procedure-oriented system Observations on Duality  the models are duals  logically identical  have identical performance

3 Canonical (simple) Models Message-oriented Model  small, static number of big processes  explicit message channels between them  limited use shared memory  context of execution with process Procedure-oriented Model  large number of small processes  rapid creation and deletion of processes  extensive use of interlocked shared memory  context of execution with function

4 Message-oriented Systems Characterized by Message (Event) Passing Facilities  efficient message passing  message queues  messaging primitives  pre-emption when 'higher priority' process receives message

5 Message-oriented Systems: Design Good Design Practices  static structure, static priorities  message queues handle synchronization for congested resources  data passed by reference in messages  peripheral devices are treated as processes  processes handle messages in batches  naming schemes are not needed

6 Message-oriented Systems: Primitives Provided Facilities  messages, message identifiers  message channels, message ports  SendMessage[ messageChannel, messageBody ] returns [ messageId ]  AwaitReply[ messageId ] returns [ messageBody ]  WaitForMessage[ set of messagePort ] returns [ messageBody, messageld, messagePort ]  SendReply[ messageId, messageBody ]  process declaration  CreateProcess

7 Procedure-oriented Systems Characterized by Procedure Call Facilities  efficient context switching  cooperation via synchronizing primitives  processes may queue on locks  lock queue favors 'higher priority' process on a lock release

8 Procedure-oriented Systems: Design Good Design Practices  process (thread) creation and destruction is cheap and dynamic  priorities are associated with the locks or data structures  lock queuing provides synchronization for congested resources  data is shared directly  data locks are kept short and small  peripheral devices are used via locks and shared memory  global naming schemes are important

9 Procedure-oriented Systems: Primitives Provided Facilities  procedures, process identifiers  procedure call facilities, synchronous and asynchronous  processld <- FORK procedureName[ parameterList ]  [ resultList ] <- JOIN processld  modules and monitors  module instantiation with NEW and START  condition variables  WAIT conditionVariable  SIGNAL condition Variable

10 Duality Given that Systems match the Canonical Models  primitive can be mapped directly  program logic and data structures are conserved  performance is preserved given identical scheduling strategies

11 Duality: Primitive Mapping Message-oriented system Processes, CreateProcess message channels message message ports SendMessage; AwaitReply (immediate) SendMessage;... AwaitReply (delayed) SendReply main message loop arms of the case statement selective waiting for messages monitors, NEW/START External procedure identifiers ENTRY procedure identifiers simple procedure call FORK;...JOIN RETURN (from procedure) monitor lock, ENTRY attribute ENTRY procedure declarations condition variables, WAIT, SIGNAL Procedure-oriented system

12 Duality: Logic and Performance Conservation of Logic  control structures are directly translated  initialization moved  no algorithms are changed  no data structures are replaced Preservation of Performance  logic stays the same  method calls and message sends have similar costs  message queuing and lock queuing have similar costs  process switching can be equally fast  virtual memory and paging can be equally fast

13 Conclusions typical systems are not perfect examples of either model both models are equally effective efficient implementation in key choice between models is based on the platform, not application choice tends to result in a full adoption of model design