Duality and UPCalls

Syed Adnan (sadnan@ucsd.edu)
Mon, 24 Apr 2000 23:15:24 -0700

Name: Syed Adnan
Date: 4-24-00
On The Duality of OS Structure

This paper argues that most of the operating system can be viewed as having one of two very general forms of internal structures. One is Message-based, and the other is Procedure-oriented. Operating system using Message-based structure uses few large processors communicating with message passing while Procedure-oriented structure consist of many small processors which are easily created and deleted, but these processes do not sends messages. Paper argues for three different points while analyzing these structures. First, paper argues that both styles have merit with respect to structure, performance, logical soundness, elegance and correctness. Second, paper tries to make designing process more constraint and systematic that once a style is chosen, designer should try to utilize the good (well-known) properties of the chosen style of system. So designer can avoid introducing a fundamental incompatibility, which can stay hidden till it's too late in the designing process. Lastly, pap
er tries to prove that these two different styles of structures are equivalent, and one must choose the type of style based on compatibility of style and hardware that is being used. Though this paper is with out any concrete prove of its claims, it does provide a very good over all view of these two structures which is very important to have while designing a new system based on these structures.
Paper starts with analysis and explanation of most properties of that particular style in operating system that have used them. For example, explanation and definition of communication paths, ports and sockets describing that how process in a message based might use to communicate. After explaining, paper creates a generic model for that particular style of structure. Paper compared and showed that how both styles can be interchanged since in both models there is one-to-one correspondence among tools and mechanisms, which can be interchange. For instance, in their model SendMessage message in message-based style is same as simple procedure call in procedure-oriented style. Paper also claims that if we change style for an operating system, it does not affect code and data structures, complexity and computations from one style to the other.
Paper mention made a point that if a system has some odd structure which doesn't follow these generic form of structure, may be that operating system doesn't have a good structure. It will be harder to port one of these structures on such an operating system.
This paper is very easy to read, and very gives us a very good over all view of these structures. One of the things came to mind that may be we should have read this paper even earlier to judge other papers from this paper's point of view that this paper breaks almost all the operating systems into two different type categories. It is very useful paper from design point of view. Author of this paper admit that this paper would be controversial that paper does not give any concrete examples of their claims. Personally, I think that there is comparison to be made between two styles, but a lot more research needs to be done in such issue. Also, I believe that these styles will not be portable even on nicely design system.

Name: Syed Adnan
Date : 4-24-00

The Structure of System Using UpCalls.

This paper argues that many operating systems failed to provide correct run time support for highly interactive parallel software, and this paper discusses a methodology suitable for operating system programs, especially programs dealing with communication and networks.
Paper claims that it is shown that asynchronous communication between layers leads to serious performance problems; therefore, this paper propose an implementation methodology, which also permits synchronous (procedure call) between layers, both when a higher layer invokes a lower layer and from lower layer to higher layer. This methodology allows programmer to whether implement an upward flow using procedure calls or use asynchronous signals. This feature is called Upcalls in this paper.
Paper defines layers as collection of subroutines, which are residing in different tasks, and each subroutine is callable as appropriate from above or below. Subroutines in different tasks make up a Multi-task module in a layer. This system was implemented in a single space address, and one of the goals is to demonstrate reliable program execution in a single address space.
One of the advantages of the swift system was flow of efficiency since it is a synchronous procedure call rather than a asynchronous inter process signals which can swamped the system with many layers. Second advantage of the system is the simplicity of the implementation that most programmers are custom to subroutine calls rather then inter-process communication. High rate of Piggyback is possible that layers are communicating, and can determine the data needed to be sent across layers.
Several of disadvantages are very serious in my opinion. If a recursive call is made to layer above, and then that layer turns around and make a procedure call from the layer that invoked it to being with can cause major problems. This problem can destroy the whole system that lower layer being destroyed could destroy all the clients attached to that particular layer. This system heavily depends on the programmer to take care of a lot of details, which is a flaw in itself. For example, distinguishing between a task in a loop and task running an unexpectedly long time is not being watched by the operating system itself. Multitask-module is also unfamiliar style of programming.
In conclusion author admit that this system is not a good system for supporting message-based system to support shared memory.
This paper has more flaws than advantages. System is not completely built, and still under development. Though few ideas are really good, disadvantages of these ideas can be serious as well. This system runs on a single address space which is controversial in itself.