On the Duality of Operating System Structures

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

5. Introduction – Concept of Duality The two categories are duals of each other Dual programs or subsystems are 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

7. Message-oriented Systems Good Design Practices: Message queuing provides synchronization of 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 ] AwaitReply[ messageId ] returns [ messageBody ] WaitForMessage[ set of messagePort ] returns [ messageBody, messageld, messagePort ] SendReply[ messageId, messageBody ] Process declaration CreateProcess

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

10. Procedure-oriented Systems Good Design Practices: Lock queuing provides synchronization of processes 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 Processes inherit priorities dynamically Global naming schemes are important

11. Procedure-oriented Systems 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 • Procedure-oriented system • 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

13. 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) ‘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 Duality Mapping: Events and Threads

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

15. 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 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) 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 Same amount of client code executed in each system Same amount of computing power required and so system performance will remain 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 Typical systems are not perfect examples of either model Empirical Paper - No proper validations for claim Performing the transformation in real life may not be so easy