On the Duality of Operating System Structures

1
On the Duality of Operating System Structures

• Hugh C. Lauer Roger M. Needham
• Presented by Stelian Coros

2
Outline

• Introduction
• Message Oriented Systems
• Procedure Oriented Systems
• The Duality Mapping
• Conclusions
• Questions

3
Message Oriented Systems (Events Based)

• Characterized by facilities for passing messages
  among processes
• Needs of application are encoded into data that
  is passed around through messages
• Common style of system architecture for real time
  systems

4
Message Oriented Systems Canonical Model

• Small, static number of big processes
• Deletion and creation of processes is difficult
• Synchronization through message queuing
• Explicit set of message channels between
  processes
• Specific communication paths (message channels,
  ports and sockets) for specific forms of
  communication
• Message passing facilities (i.e. sending and
  queuing messages)

5
Message Oriented Systems Canonical Model

• Limited amount of directly shared data
• Each process operates in a static context
• One-to-one correspondence between virtual
  memories/address spaces and processes

6
Message Oriented Systems good design practices

• Data passed by reference in messages
• Peripheral devices treated as processes
• Static assignment of priorities to processes
• No global naming schemes

7
Message Oriented Systems

• Implementation of operations such as
• SendMessage
• AwaitReply
• WaitForMessage
• SendReply
• CreateProcess

8
Procedure-oriented System (Thread Based)

• System resources encoded in global data
  structures
• Cooperation among processes achieved through
  locks, semaphores, monitors, etc
• Style characteristic of a wide variety of designs

9
Procedure Oriented Systems Canonical Model

• Inter-process communication through direct
  sharing of global data
• Synchronization achieved by locking
• Large number of small processes
• Creating and deleting processes is relatively
  easy
• Each process has only one goal
• May wonder about the system in order to do it

10
Procedure Oriented Systems good design practices

• data is shared directly
• processes lock small part of the data, for short
  periods of time
• peripheral devices are handled by manipulating
  locks and shared memory
• global naming schemes are important

11
Procedure Oriented Systems

• Implementation of operations such as
• Fork
• Join
• New/Start for modules and monitors
• Wait
• Signal

12
The models

• rather idealized
• most systems are implemented with one of the two
  styles
• or can be decomposed into subsystems
• most of the rest of the systems are
  ill-structured, unstable, unreliable,
  unmanageable, uneconomic and unusable

13
The Duality Mapping

• Concept of duality
• Program defined using one model can be mapped
  directly into another program that uses the other
  model
• The two programs are logically identical to each
  other
• They also have the same performance

14
The Duality Mapping

• Procedure-oriented system

• 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
Direct mapping between the basic primitives of
the two models
15
Similarity of Programs

• Switching between the types of primitives does
  not affect the logic of the programs
• No algorithms or data structures need to be
  changed
• Main bodies of programs are untouched
• Execution times of the programs themselves do not
  change same performance

16
Preservation of Performance

• method calls (e.g Fork) and sending messages have
  similar costs
• message queuing and lock queuing have similar
  costs
• process switching can be equally fast
• virtual memory and paging can be used with equal
  effectiveness

17
Duality

• Programs can be mapped from one style to another
• without changing the logic of the programs
• without affecting performance
• Empirical Supprt
• For accidental reasons, it is not very easy to
  change the structure of most operating systems in
  a way which would reflect the duality we suggest.
  Accordingly, there is not much evidence of
  example which can be quoted in support of our
  thesis.

18
Conclusion

• No inherent difference between the two models
• Neither model is inherently preferable
• Choice is based on architecture, not application
• Analysis works on idealized canonical models
• Real systems do not fit the profile
• No formal, rigorous proof for the claims
• The analysis is likely to be controversial

19
Questions

• Even if this duality holds, it seems to miss the
  point that the main problem with event-based
  versus thread-based systems lie with
  theprogrammer. This is more of a comment than a
  question, but it doesn't seem very compelling to
  say that there "is a duality" between these
  systems while one may be easier to code than the
  other (and as aresult less error-prone).

20
Questions

• This paper is purely empirical, there are no data
  given or experiments done to support their ideas.
  In fact, the authors even admit on page 15 that
  time will tell whether they are correct.  Do
  you think they have a strong case?  What has time
  told us?  What advances have affected this
  argument since the paper was written?

21
Questions

• If message-based and process-based are duals and
  have similar performance, shouldn't message-based
  be preferred because of the separation of address
  spaces? But most modern kernels seem to be
  process-based kernels. Why is this?

22
Questions

• Do people think that the duality concept still
  exists today? Most of the other papers that weve
  read on this topic seem to say one of events and
  threads is better than the other, or at least
  some aspects are better.

23
Questions

• A conclusion that the authors are drawing is that
  if the code is hard to convert from a model to
  another, then it ought to be ill-structured. In
  defending their case they only provide one
  example on page 13 in the fourth paragraph. Does
  providing a single example enough to draw this
  conclusion?