On the Duality of Operating System Structures 1
Description: On the Duality of Operating System Structures 1 Hugh C. Lauer Xerox Corporation Palo Alto, California Roger M. Needham Cambridge University Cambridge, England Proc. Second International Symposium on Operating Systems, IRIA, Oct. 1978 2
Related Topics
Download Presentation
"On the Duality of Operating System Structures 1" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
slide1. On the Duality of Operating System Structures 1<br>
slide2. Hugh C. Lauer
Xerox Corporation
Palo Alto, California
Roger M. Needham
Cambridge University
Cambridge, England Proc. Second International Symposium on Operating Systems, IRIA, Oct. 1978 2<br>
slide3. Overview
Nature of the Paper
Two Models
Message-Oriented Systems
Procedure-Oriented Systems
Characteristics of the Models
Empirical Support
Underlying Similarities
Underlying Differences
Conclusions Outline 3<br>
slide4. “Many operating system designs can be placed into one of two very rough categories, depending upon how they implement and use the notions of process and synchronization.” Overview 4<br>
slide5. The paper is empirical in nature
The universe in the investigation is the class of operating systems
The properties of interest are processes, synchronization and inter-process communication Nature of the Paper 5<br>
slide6. Two Models Message-Oriented Systems Procedure-Oriented Systems 6<br>
slide7. Characterized by a relatively small, static number of processes with an explicit message system for communicating among them Message-Oriented Systems 7<br>
slide8. Specific communication paths
Relatively static number of processes and connections
Deletion of processes tends to be very difficult Hallmarks 8<br>
slide9. Messages
A message is a data structure meant for sending information from one process to another
Message Identifiers
A message identifier is a handle by which a particular message can be identified
Message Channels
A message channel is an abstract structure which identifies the destination of the message
Message Ports
A message port is a queue capable of holding messages of a certain type or class Facilities 9<br>
slide10. SendMessage [messageChannel, messageBody] returns [messageId]
AwaitReply [messageId] returns [messageBody]
WaitForMessage [set of messagePort] returns [messageBody, messageId, messagePort]
SendReply [messageId, messageBody] Message Transmission Operations 10<br>
slide11. IBM’s OS/360
A discontinued batch processing operating system developed by the IBM Corporation for their then-new System/360 mainframe computer, announced in 1964
GEC 4080
16-bit minicomputer with its unique Nucleus feature (Marconi-Eliot Division) Examples 11<br>
slide12. Characterized by a large, rapidly changing number of small processes and a process synchronization mechanism based on shared data Procedure-Oriented Systems 12<br>
slide13. Global data can be both protected and efficiently accessed
Process creation is very easy Hallmarks 13<br>
slide14. Procedures
A procedure is a piece of Mesa text containing algorithms, local data, parameters and results.
Procedure call facilities – synchronous and asynchronous
The synchronous procedure call mechanism is just the ordinary Mesa procedure call statement
The asynchronous procedure call mechanism is represented by the FORK and JOIN statements
Modules and Monitors
A module is the primitive Mesa unit of compilation
A monitor is a special kind of Mesa module which has associated with it a lock to prevent more than one process from executing inside of it at any one time
Module Instantiation
Modules may be instantiated in Mesa by means of the NEW and START statements
Condition Variables
Condition Variables provide more flexible synchronization among events Facilities 14<br>
slide15. HYDRA
An early capability-based, object-oriented, microkernel implemented in the programming language BLISS as part of the C.mmp project at Carnegie-Mellon University
Plessey System 250
Capability-based multiprocessing operating system kernel Examples 15<br>
slide16. The Duality Mapping
Similarity of Programs
Preservation of Performance Characteristics of the Models 16<br>
slide17. A program or subsystem constructed strictly according to the primitives defined by one model can be mapped directly into a dual program or subsystem which fits the other model. The Duality Mapping 17<br>
slide18. The dual programs or subsystems are logically identical to each other.
They can also be made textually very similar, differing only in non-essential details. Similarity of Programs 18<br>
slide19. The performance of a program or subsystem from one model, as reflected by its queue lengths, waiting times, service rates, etc. is identical to that of its dual system given identical scheduling strategies.
The primitive operations provided by the operating system of one model can be made as efficient as their duals of the other model. Preservation of Performance 19<br>
slide20. It is not very easy to change the structure of most operating systems in a way which would reflect the duality
The underlying address structures, use of global data, and styles of communication are usually bound to the design and implementation
The Cambridge CAP Computer Empirical Support 20<br>
slide21. Comparison of the Two Models 21<br>
slide22. The two styles lead to client systems with similar program structure and performance
The computational complexity of the implementation of the system facilities to provide the two styles is similar Underlying Similarities between Styles 22<br>
slide23. Machine Architecture
Programming Environment Underlying Differences between Styles 23<br>
slide24. There lies merit in both styles with respect to structure, performance, logical soundness, elegance and “correctness”.
Neither model is inherently preferable.
The main consideration is the machine architecture upon which the system is being built, not the application which the system will ultimately support. Conclusions 24<br>
slide25. Presented By:
Amna Rafiq
Graduate Student
CS @ VT Thank you! 25<br>
slide2. Hugh C. Lauer
Xerox Corporation
Palo Alto, California
Roger M. Needham
Cambridge University
Cambridge, England Proc. Second International Symposium on Operating Systems, IRIA, Oct. 1978 2<br>
slide3. Overview
Nature of the Paper
Two Models
Message-Oriented Systems
Procedure-Oriented Systems
Characteristics of the Models
Empirical Support
Underlying Similarities
Underlying Differences
Conclusions Outline 3<br>
slide4. “Many operating system designs can be placed into one of two very rough categories, depending upon how they implement and use the notions of process and synchronization.” Overview 4<br>
slide5. The paper is empirical in nature
The universe in the investigation is the class of operating systems
The properties of interest are processes, synchronization and inter-process communication Nature of the Paper 5<br>
slide6. Two Models Message-Oriented Systems Procedure-Oriented Systems 6<br>
slide7. Characterized by a relatively small, static number of processes with an explicit message system for communicating among them Message-Oriented Systems 7<br>
slide8. Specific communication paths
Relatively static number of processes and connections
Deletion of processes tends to be very difficult Hallmarks 8<br>
slide9. Messages
A message is a data structure meant for sending information from one process to another
Message Identifiers
A message identifier is a handle by which a particular message can be identified
Message Channels
A message channel is an abstract structure which identifies the destination of the message
Message Ports
A message port is a queue capable of holding messages of a certain type or class Facilities 9<br>
slide10. SendMessage [messageChannel, messageBody] returns [messageId]
AwaitReply [messageId] returns [messageBody]
WaitForMessage [set of messagePort] returns [messageBody, messageId, messagePort]
SendReply [messageId, messageBody] Message Transmission Operations 10<br>
slide11. IBM’s OS/360
A discontinued batch processing operating system developed by the IBM Corporation for their then-new System/360 mainframe computer, announced in 1964
GEC 4080
16-bit minicomputer with its unique Nucleus feature (Marconi-Eliot Division) Examples 11<br>
slide12. Characterized by a large, rapidly changing number of small processes and a process synchronization mechanism based on shared data Procedure-Oriented Systems 12<br>
slide13. Global data can be both protected and efficiently accessed
Process creation is very easy Hallmarks 13<br>
slide14. Procedures
A procedure is a piece of Mesa text containing algorithms, local data, parameters and results.
Procedure call facilities – synchronous and asynchronous
The synchronous procedure call mechanism is just the ordinary Mesa procedure call statement
The asynchronous procedure call mechanism is represented by the FORK and JOIN statements
Modules and Monitors
A module is the primitive Mesa unit of compilation
A monitor is a special kind of Mesa module which has associated with it a lock to prevent more than one process from executing inside of it at any one time
Module Instantiation
Modules may be instantiated in Mesa by means of the NEW and START statements
Condition Variables
Condition Variables provide more flexible synchronization among events Facilities 14<br>
slide15. HYDRA
An early capability-based, object-oriented, microkernel implemented in the programming language BLISS as part of the C.mmp project at Carnegie-Mellon University
Plessey System 250
Capability-based multiprocessing operating system kernel Examples 15<br>
slide16. The Duality Mapping
Similarity of Programs
Preservation of Performance Characteristics of the Models 16<br>
slide17. A program or subsystem constructed strictly according to the primitives defined by one model can be mapped directly into a dual program or subsystem which fits the other model. The Duality Mapping 17<br>
slide18. The dual programs or subsystems are logically identical to each other.
They can also be made textually very similar, differing only in non-essential details. Similarity of Programs 18<br>
slide19. The performance of a program or subsystem from one model, as reflected by its queue lengths, waiting times, service rates, etc. is identical to that of its dual system given identical scheduling strategies.
The primitive operations provided by the operating system of one model can be made as efficient as their duals of the other model. Preservation of Performance 19<br>
slide20. It is not very easy to change the structure of most operating systems in a way which would reflect the duality
The underlying address structures, use of global data, and styles of communication are usually bound to the design and implementation
The Cambridge CAP Computer Empirical Support 20<br>
slide21. Comparison of the Two Models 21<br>
slide22. The two styles lead to client systems with similar program structure and performance
The computational complexity of the implementation of the system facilities to provide the two styles is similar Underlying Similarities between Styles 22<br>
slide23. Machine Architecture
Programming Environment Underlying Differences between Styles 23<br>
slide24. There lies merit in both styles with respect to structure, performance, logical soundness, elegance and “correctness”.
Neither model is inherently preferable.
The main consideration is the machine architecture upon which the system is being built, not the application which the system will ultimately support. Conclusions 24<br>
slide25. Presented By:
Amna Rafiq
Graduate Student
CS @ VT Thank you! 25<br>