1. On the Duality of Operating System Structures
Hugh C. Lauer & Roger M. Needham
Presented by: Stelian Coros

2. Outline Introduction The Duality Mapping Conclusions Questions
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 Message-oriented system Procedure-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 the programmer. 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 a result 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 we’ve 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?