1. The Structuring of Systems Using Upcalls By David D. Clark Presented by Samuel Moffatt

2. Layering  Application Organization Technique Separate functional components that interact in some hierarchical manner. There is typically only an interface to the layer above. Top down flow. Client requests services of the layer below Using a process to implement a layer is standard at this time and requires expensive interprocess communications to communicate between layers.

3. Layering in Operating Systems  Pros Verification Organization  Cons Upward flow not well supported  Asynchronous mechanisms, extra overhead

4. Upcall  A procedure call from a lower layer into the layer above. Causes control flow to go “up” Breaks “depends on” or “using” relationship of traditional layering Network protocols are designed with an upflow. Not efficiently supported at the time using interprocess communications.

5. Multi-task Module  “Subroutines in different tasks that collaborate with each other through shared state.” A layer.  A task is a single thread of execution with subroutine calls for up and downcalls.  Shared memory access controlled via locks.  “Intertask” communication occurs only within a layer.

6. Multi-task Module

7. Network Protocol Implementation Example

8. Upcall Benefits  Synchronous subroutine calls instead of asynchronous signals  Helps to support “piggybacking” of information in network protocols.  Simplicity of implementation Eliminates buffering code for signals Lower layer can ask advice of upper layer. Programmer familiarity with subroutines Hide implementation details

9. Upcall Problems  A failed upcall can corrupt the layer and clients of that layer.  Solution Separate data. Local data and shared data. Shared data must be made consistent and unlocked before a call. If there is an error, may destroy a task (vertical stripe) in the system but resources can be recovered and if shared data is consistent then other tasks are not affected. Cleanup methods to recover resources.

10. Upcall Problems  Indirect recursive call  Solutions 1. Put all variables in a consistent state before making an upcall then re-evaluate state on return. 2. Prohibit recursive downcalls. 3. Have downcall perform action directly or queue execution by task holding a required lock. Good for interrupt handlers. 4. Downcalls never perform significant actions. Only simple things, like set flags. 5. Use a special upcall to collect data instead of a downcall.

11. Task Scheduling  Priority of a task Uses a deadline time instead of a number sequence. Easier to understand. Mutable. Assigned each time the process is scheduled.  If a long deadline task is blocking a short deadline task the long task will be temporarily promoted.

12. Single Address Space  Single address space for efficiency.  Programmed with CLU which provides compile time and runtime checks to protect the address space from corruption.  Garbage collection instead of user destroying objects. No longer valid pointer protection.  The above mitigate damage on failure so debugger can still run.

13. Conclusions  Upcalls are useful Efficiency and simpler code.  Multi-task modules are useful in organizing the system.  “Strongly checked typesafe languages” is useful in a single address space.  Decomposing the operating system into vertical stripes representing user requests is better than using a process as a layer.  Shared memory is a good communication tool. Not using shared memory would require a task to manage state variables that were in the shared memory.