1. On the Duality of Operating System Structures Hugh C. Lauer Xerox Corporation Roger M. Needham Cambridge University Presented By: Ashwini Kulkarni

2. Agenda  Introduction  Elaboration – Message-oriented Systems  Elaboration – Procedure-oriented Systems  Duality between the two systems  Events and Threads as duals  Conclusion

3. Introduction Categories of operating systems:  Message-oriented System:  Small, static number of big processes  Explicit set of message channels  Limited amount of direct sharing  Context of execution with processes

4. Introduction  Procedure-oriented System:  Large number of very small processes  Rapid creation and deletion of processes  Extensive use of interlocked shared memory  Context of execution with function being executed executed

5. Introduction – Concept of Duality  The two categories are duals of each other other  Dual programs or subsystems are logically identical to each other logically identical to each other  Have identical performance

6. Message-oriented Systems (Message Passing) Characterized by:  Execution is in separate address spaces  Message passing facilities  Message queuing  Messaging primitives  Processor pre-emption occurs when 'higher priority' process receives message priority' process receives message

7. Message-oriented Systems Good Design Practices:  Message queuing provides synchronization of processes and queuing of congested resources processes and queuing of congested resources  Data passed by reference in messages  Peripheral devices treated as processes  Static assignment of priorities to processes  No global naming schemes

8. Message-oriented Systems Facilities:  Messages, Message identifiers  Message channels, Message ports  Message Transmission operations:  SendMessage[ messageChannel, messageBody ] returns [ messageId ] [ messageId ]  AwaitReply[ messageId ] returns [ messageBody ]  WaitForMessage[ set of messagePort ] returns [ messageBody, messageld, messagePort ] [ messageBody, messageld, messagePort ]  SendReply[ messageId, messageBody ] Process declaration Process declaration CreateProcess CreateProcess

9. Procedure-oriented Systems (Shared Memory) Characterized by:  Protection and addressing mechanism  Rapid context switching  Cooperation among processes via synchronizing primitives synchronizing primitives  Processes queue on locks  Lock queue favors 'higher priority' process on a lock release on a lock release

10. Good Design Practices:  Lock queuing provides synchronization of processes and queuing of congested resources and queuing of congested resources  Direct sharing of data among processes  Data locks are kept short and small  Creation and deletion of a process is cheap and easy  Interaction with peripheral devices is through shared memory memory  Processes inherit priorities dynamically  Global naming schemes are important Procedure-oriented Systems

11. Facilities:  Procedures  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 conditionVariable

12. Duality: Primitive Mapping Message-oriented system Processes, CreateProcess Message Channels 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

13. Duality Mapping: Events and Threads Event handler for sending a message which blocks waiting for reply Separate event handlers for sending message and waiting for reply Event handler for replying to a message Main event handling loop in event-based systems Invocation of an appropriate event handler Events wait in the event queue until they are processed Normal procedure call, by a thread, which returns (like Mesa procedure call) (like Mesa procedure call) ‘Forking’ a thread and then ‘joining’ it Return from a procedure call Acquiring of the mutual exclusion lock on the monitor by a thread Execution of an ENTRY procedure of a monitor by a thread Threads wait on condition variables until some event or condition has occurred

14. Accept Connection Read Request Find File Send Header Read File Send Data A Process made of multiple events Accept Connection Read Request Find File Send Header Read File Send Data Event Dispatcher Socket()Read()Find()Send() Event handlers N such processes Main event handling loop in event-based systems

15. Accept Connection Read Request Find File Send Header Read File Send Data Accept Connection Read Request Find File Send Header Read File Send Data Monitor (Acquire Lock of a shared resource) N such threads Accept Connection Read Request Find File Send Header Read File Send Data Accept Connection Read Request Find File Send Header Read File Send Data Acquiring of the mutual exclusion lock on the monitor by a thread

16. Duality: Logic  Similarity of Programs:  Control structures directly translated  Initialization code moved  No algorithms changed  No data structures replaced  No interface strategies affected

17. Duality: Performance  Preservation of Performance:  Algorithms compute at the same speed  Same amount of information stored in each data structure data structure  Same amount of client code executed in each system system  Same amount of computing power required and so system performance will remain and so system performance will remain unchanged unchanged

18. Conclusions  No inherent difference between the two models  Neither model is inherently preferable  Choice between models is based on platform and not the application and not the application  Typical systems are not perfect examples of either model either model  Empirical Paper - No proper validations for claim  Performing the transformation in real life may not be so easy may not be so easy