The Structuring of Systems Using Upcalls David D. Clark Presenter: Haitham Gad
Layered Program Structure • Layering is a program structure proposed for usage in operating systems and network protocols. • System functions are organized as layers. • Upper layers are thought of as clients to lower layers ( lower layers provide services to upper layers ) . • Acyclic dependency relationship among layers enhances modularity and facilitates verification.
Layered Program Structure • Layers are traditionally implemented in the form of OS processes ( or threads ) . • Service invocation occurs from the top down through subroutine calls ( probably RPC ) . • Upward flow of control, when needed, is implemented using interprocess communication signals. • This methodology, however, leads to serious performance and code complexity problems.
Motivation for Upcalls • In a layered program structure, the natural flow of control is often upward not downward. • In a process - based layer implementation, upward flow of control is ine ffi cient due to: - The need for data bu ff ering mechanisms; - The need for interprocess signals. • Upward flow of control requires contaminating layer code with a lot of communication code.
Multi - task Modules • A layer is organized as subroutines that live in a number of tasks. • Invocation across layer boundaries is done only through subroutine calls. • Shared state among subroutines is managed by a monitor lock. • The group of collaborating subroutines from di ff erent tasks are called a multi - task module .
Multi - task Modules • Intertask communication can only be used within a layer. interprocess commun ication rnultitask modules subroutine calls F igure I: Illustration of System Organization Note that there are many other ways which the receive natural flow of control dictates. As the figure shows, intertask function could have been organized using upcalls. The net- communication only occurs in a horizontal direction, between the various tasks in a layer, while flow of control between layers is dispatch routine could have selected an anonymous task, rather than one specifically associated with the particular port in achieved between through subroutine calls, both up and down: question. In Swift, we tended to use yet another approach, in which there was one single task associated with the processing of 4 An Example all incoming packets. This latter approach works fine, unless the processing at a high level consumes a great deal of time, in which Before proceeding to a more detailed defense of this ease the processing of other packets may be delayed. methodology, an example may help illustrate the concepts of upcall and multi-task module in practice. Since the The processing of received packets seems to fit rather programming style was initialy motivated by network protocols, naturally into the upcall philosophy. A packet is received, and we will use that as an example. Figure 2 illustrates a skeleton the processing of that packet must necessarily proceed from the implementation of a three layer protocol package that provides a lower layers to the higher, however that flow is achieved. On remote login service. The bottom layer is responsible for the other hand, it might superficially seem that the sending of a dispatch of incoming packets to the correct transport service. packet would more naturally proceed from above. The client, The transport layer organizes the packets into the correct having some data to send, would invoke a transport module to sequence, detects lost or duplicate packets, etc., and delivers the format a packet, which would in turn invoke a network layer data, in this ease one character at a time, to the remote login module to send the packet. A closer inspection of network layer, which performs display management. Each layer protocols reveals, however, that sending as well as receiving is represents an instance of a multi-task module. This figure properly structured using upcalls. The reason for this is that in includes the connection initiation code, which involves the most cases, the decision as to when a packet is sent is not downcall sequence, and incoming packet processing which, fairly determined by the client, but by the flow control mechanism of naturally, involves an upcall. There are actually two upealls the transport protocol, and the congestion control mechanism of illustrated as part of packet receipt. The subroutine net-dispatch the network layer. In a simple implementation of a network is upealled as part of the interrupt handler, and in turn upealls protocol, one is tempted to ignore real life resource management the transport layer to determine which transport level entity issues, such as flow and congestion control, but in fact they are should receive this packet. Using this information, it selects the the heart of protocol processing, and dictate the program task from a table, and then signals that task. That task correct structure. Figure 3, therefore illustrates the companion modules in turn starts running by executing the program net-receive, for sending packets, which take into account the necessity of which in turn upcalls the transport layer (the subroutine implementing transport layer flow control. In this example there transport.receive), which in turn upcalls the subroutine display- is both an upcall and a downcall. The downcall notifies the receive. 173
Recommend
More recommend
