On the Duality of Operating System Structures Hugh

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

Outline n Introduction q q n n n Message Oriented Systems Procedure Oriented Systems The Duality Mapping Conclusions Questions

Message Oriented Systems (Events Based) n Characterized by facilities for passing messages among processes n Needs of application are encoded into data that is passed around through messages n Common style of system architecture for real time systems

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

Message Oriented Systems – Canonical Model n Limited amount of directly shared data q q Each process operates in a static context One-to-one correspondence between virtual memories/address spaces and processes

Message Oriented Systems – good design practices n Data passed by reference in messages n Peripheral devices treated as processes n Static assignment of priorities to processes n No global naming schemes

Message Oriented Systems n Implementation of operations such as q q q Send. Message Await. Reply Wait. For. Message Send. Reply Create. Process

Procedure-oriented System (Thread Based) n System resources encoded in global data structures n Cooperation among processes achieved through locks, semaphores, monitors, etc n Style characteristic of a wide variety of designs

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

Procedure Oriented Systems – good design practices n data is shared directly n processes lock small part of the data, for short periods of time n peripheral devices are handled by manipulating locks and shared memory n global naming schemes are important

Procedure Oriented Systems n Implementation of operations such as q q q Fork Join New/Start for modules and monitors Wait Signal

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

The Duality Mapping n Concept of duality q q q 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

The Duality Mapping n Message-oriented system n Procedure-oriented system Processes, Create. Process monitors, NEW/START External message channels message procedure identifiers ENTRY message ports procedure identifiers simple Send. Message; Await. Reply (immediate) procedure call Send. Message; . . . Await. Reply (delayed) FORK; . . . JOIN Send. Reply RETURN (from procedure) monitor main message loop lock, ENTRY attribute arms of the case statement selective ENTRY procedure declarations waiting for messages condition variables, WAIT, SIGNAL Direct mapping between the basic primitives of the two models

Similarity of Programs n Switching between the types of primitives does not affect the logic of the programs q q n 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

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

Duality n Programs can be mapped from one style to another q q n without changing the logic of the programs without affecting performance Empirical Supprt q “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. ”

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

Questions n 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).

Questions n 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?

Questions n 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?

Questions n 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.

Questions n 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 illstructured. 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?