Using Object-Oriented Techniques in Microkernel ... - Semantic Scholar

Using Object-Oriented Techniques in Microkernel Based Operating Systems Tatsuo Nakajima

Keio University 3-14-1 Hiyoshi Kohoku-ku, Yokohama 223, JAPAN [email protected]

large scale systems. Using objects makes the structure of systems clear, provides us extensibility and makes the maintenance of software easy. Operating systems can also be written by object-oriented languages. Several operating systems like Chorus[13] and Choice[14] use objectoriented languages to write operating system kernels, but the internal structuring does not contribute to the modularity of applications because these kernels do not provide object-oriented abstraction to application programmers. In COOL[9] and SOS[16], object-oriented interface is offered to users. Applications enjoy the bene t of the interface for better structuring, but system servers cannot use the structuring tool because the interface is provided on top of the servers. In microkernel based operating systems, system servers are realized as user level applications. Microkernels should provide structuring tools not only to applications but also to system servers. However, structuring tools provided by current microkernels are too heavy for the structuring inside system servers. Our claim is that object model required by system servers is dierent from the model for applications. Uniformity, programability and persistence are more important for applications, but we should concentrate on performance and exibility for system servers. Our goal is to de ne structuring tools for both system servers and applications for microkernel based operating systems. We consider the following two issues which are important to achieve this goal.

Abstract

Advanced future applications require to exploit new types of objects such as continuous media objects and distributed objects. Such new requirements stress operating systems to support variable levels of responsiveness and reliability. One computational model and resource management policy cannot cover the various requirements from all users so a exible structure is important when building future distributed systems to ensure such requirements. The microkernel is a good starting point to build such exible distributed systems. Current microkernel technologies, however, do not provide structuring tools for the internal structuring of microkernels and the system servers. In this paper, we describe object-oriented structuring techniques to be used in microkernel based operating systems. First, we survey several existing systems which use object-oriented techniques. Next, we describe objectoriented techniques used in Real-Time Mach in depth. Lastly, we discuss the architectures of microkernel based operating systems. 1

Introduction

Modularity is widely recognized as a necessary tool in the building large distributed systems. By dividing systems into small, easily managed pieces, modularity provides advantages in organization and veri cation throughout the life of systems. Modularity is de ned by separated system components joined by a well de ned interface. Microkernel is a good starting point to build modular and exible operating systems. Traditional operating systems are divided into a microkernel and system servers. Many traditional abstraction such as les, TTYs and inter machine communication ports are provided by system servers. A new abstraction can be provided by adding a new server and an existing abstraction can be improved to replace an existing server. Object-oriented techniques are useful tools to structure

 Flexible structuring tools to support multiple models.  Close integration of microkernel and run-time sys-

tems.

In this paper, we show several examples to prove the above issues and discuss the structuring techniques in microkernel based operating systems. First, we survey several examples to use object-oriented techniques in operating systems. Next, we present a detailed discussion about the object-oriented techniques used in Real-Time Mach kernel and our prototype system servers on Mach. Lastly, 1

Aplication

Pseudo Server NFS Application

File Server

TTY Server

Process Server

File

Network Server

Device

Remote File

Remote Device

Sprite Kernel Micro Kernel

Figure 1: Structure of Microkernel

Figure 2: Structure of File Objects in Sprite

The rst issue requires the restructuring of the architecwe discuss the architecture of microkernel based operating ture of microkernel based operating systems and better insystems. tegration of microkernels and run-time systems. The second and third issues make it necessary to use other exist2 Large and Fine Grained Struc- ing object-oriented language when writing system servers, In section 3, we show the object-oriented techniques which turing are used in existing operating systems to provide high level Microkernel design is one approach to build modular op- abstraction. In section 4, the object-oriented techniques erating systems. Traditional operating systems are di- which are used in the processor scheduler and the synchrovided into three layers, a microkernel layer providing mem- nization module in Real-Time Mach are described. In secory management, process control and simple inter-process tion 5, we show the architecture of our prototype system communication, a system server layer supporting the re- servers and discuss these internal structures using objectmainder of the traditional operating systems including ac- oriented techniques. Finally, we discuss the architecture counting, protection, le system, network services, and op- of microkernel based operating systems in section 6. erating system emulations(Figure 1), and an application layer. One such microkernel, Mach[5] provides address 3 Structuring Techniques in Exspace and IPC as structuring tools. These structuring isting Systems tools are heavy to be used for ne grained structuring. Many objects are managed in each server and applications use IPC to send a message to the servers to access Several existing systems use object-oriented techniques objects so that performance is degraded if operating sys- to make its structure clear. For example, Sprite[21], tems are decomposed into many servers. Consequently, kernel[7] and Ficus[6] use object-oriented techniques for we need much scalable structuring tools for the internal better structuring. Even, traditional operating system like Unix uses object-oriented techniques in its le systems[8]. structuring of applications and system servers. It is frequently suggested that system servers should be In this section, we review these systems and discuss how written by object-oriented languages such as C++. The object-oriented techniques are used. approach causes the following issues. 3.1

 Two level abstraction, address spaces and objects

Unix

Unix uses object-oriented techniques to support a polymorphic interface for le systems. Accessing les, devices and networks can use the same interface, read and write[8].  Language provides only one object model. The polymorphic interface enables the same Unix appli Language provides only one memory management cations to read and write from/to les, devices, and netpolicy. works without changing applications. These functions are makes programming dicult.

2

3.3

Ficus

Ficus proposes a stackable layer to construct exible le systems. Each layer has the same syntactic same interface so that new layers can be added and removed, or replace existing layers easily. For example, new functionalities such as replication, caching, compression, and encryption can be added easily by inserting new stacks(Figure 3). Traditional le system switches provide support for multiple le systems, but cannot be used to enhance the functionality of le systems. For example, in order to add such new functionalities, one must rewrite existing le systems. In Ficus, the interface is extensible. Extra operations can be added to new layers without changing other layers. These operations should be forwarded to lower layers if some intermediate layers do not support the operations. For example, the replication layer needs extra operations to control replica of les. These operations should be sent to physical le layers which reside in remote sites without changing the interface of the remote le access layers which are the intermediate layer between replication layers and physical le layers. Traditional object-oriented languages cannot realize the mechanism. Ficus uses C not object-oriented languages such as C++.

System Call Layer

Replication Layer

NFS Layer

Physical File Layer

Figure 3: Structure of Ficus Stackable Layer

implemented for each object and the requests select suitable operations for each object. The vnode interface is also supported in various Unix systems to access dierent le systems such as Unix le system, VMS le system, and MSDOS le system without modifying applications. The stream interface[12] is also useful to access devices 3.4 -kernel in uniform ways. Special functionality such as encryption and compression can be inserted easily without modifying -kernel uses object-oriented techniques to construct protocol stacks(Figure 4). All protocol objects provide the other parts of operating systems. same syntactic interface so that the objects can be combined as graphs to represent protocol stacks. New protocols can be created by the composition of existing proto3.2 Sprite cols. In protocol graphs, objects may have several parent In the Sprite le system, all objects provided by the le objects. For example, IP has UDP and TCP as parent system can be accessed by uniform interface whether the objects. IP protocol object sends packets to upper layer, objects reside in local site or remote site. All objects TCP and UDP protocol objects using a protocol ID eld are accessed location transparently from users(Figure 2). in IP header. Upper protocol objects may have several Sprite provides two interface, naming interface and device lower protocol objects. When receiving packets from upinterface. The naming interface enables one to use a uni- per protocol objects, protocol objects select suitable protoform global name space for all objects provided by Sprite col objects using the destination address information. For le systems and objects are accessed uniformly by device example, IP sends packets to suitable Ethernet protocol interface. These two interfaces can separate naming is- objects using routing information. Virtual protocol obsues and object speci c issues. Sprite discusses two issues jects have several lower objects. -kernel proposes a new about structuring of systems to provide exibility and ef- type of protocol objects, virtual protocols. Virtual pro ciency. For achieving eciency, critical objects such as tocol objects select lower protocol objects using address le objects and directory objects are provided by Sprite information to bypass unnecessary functions such as fragkernel. These objects are accessed through trap calls not mentation and add extra functions such as ow control to IPC or RPC. For extensibility, Sprite provides pseudo le ll the gap between local and wide area network. objects and pseudo device objects. These objects are imEach system should select a suitable protocol graph by plemented in user level servers. File system in the ker- the requirement of users. For example, some systems do nel forward the requests to these servers via upcall us- not need TCP to reduce the size of systems and some sysing IPC. Accessing these objects is slower than accessing tems need to support special protocol for real-time and re le objects, but the decision can reduce the size of kernel. liable computing. In its architecture, the implementation Sprite shows that modular structure of kernels solve many of message sending is very similar to C++ virtual funcproblems in traditional monolithic kernels. tion, but the implementation of object creation is highly 3

SCP

UDP

Polymorphic interface is realized using traditional object-oriented languages, but stackable interface may not be supported well by these languages because an extensible interface as in Ficus is dicult to represent and the composition of objects may prefer speci c inheritance model.

TCP

ICMP

4

VIP

Object-Oriented Techniques in Real-Time Mach

IP

In this section, we describe the motivation to use objectoriented techniques in Real-Time Mach[18, 19, 20]. First, we show the motivation behind Real-Time Mach and give its brief overview. Next, we present general discussions of object-oriented techniques used in Real-Time Mach.

ARP Ether

Figure 4: Structure of -kernel Protocol Graph

4.1

Real-Time Operating Systems

The support of real-time facility becomes very important in future distributed computing environment. New advanced workstations are equipped with a microphone, speakers, and audio/visual coprocessors and are beginning to handle various media information such as realtime video images, animation, high quality sounds, and digitized voice routinely. Although the quality of such data will totally depend upon the completion time of the data manipulation functions, many non real-time operating systems do not provide real-time thread management 3.5 Summary and scheduling support for predictable computing. We summarize the advantages to use uniform interfaces in In traditional operating systems, real-time operating the following ways. systems and non real-time operating systems are completely separated. Future workstation operating systems  It is possible to access dierent objects through same should support both real-time activities and non real-time interface. activities. It should allow us to integrate real-time activities like continuous media applications and traditional  Adding new functionalities for adding and removing applications on workstations like editors, compilers and objects to existing abstraction. mail systems. optimized for critical objects, session objects. Session objects which maintain the states of communication are allocated and deallocated frequently. The performance of the allocation/deallocation is sensitive for better performance. However, traditional object-oriented languages do not support the mechanism to control memory allocation policies.

We call the rst advantage the polymorphic interface and the second advantage the stackable interface. The polymorphic interface is used to access dierent objects through a same syntactic interface. Several types of objects are accessed by the same interface so that applications access dierent objects without changing applications. The stackable interface is used to composite several objects. From the point of view of users, a composite object can be seen as one object. Users can add, remove, and replace objects at any time for changing the functionality of existing objects. For example, recovery, persistence, multicast communication should be added to existing abstractions, because objects have a symmetric interface and it could be inserted into existing stacks at any layer boundary.

4.2

Overview of Real-Time Mach

The Real-Time Mach kernel has the following three characteristics over the original Mach kernel.  Real-Time Thread Model.  ITDS Scheduler.  Multiple Lock Policies.

In Real-Time Mach, a thread can be de ned for a realtime or non-real-time activity. For a real-time thread, additional timing attributes must be de ned by a timing attribute descriptor. A real-time thread can be de ned as a hard real-time or soft real-time thread. A real-time thread can be also de ned as a periodic or aperiodic thread 4

based on the nature of its activity. The scheduler needs to notify these distinctions and select the highest priority thread according to a scheduling policy. The integrated time-driven scheduling model(ITDS) provides predictability, exibility, and modi ability for managing both hard and soft real-time activities in various real-time applications. For hard real-time activities, the ITDS model allows a system designer to predict whether the given task set can meet its deadlines or not. For soft real-time activities, the designer may predict whether the worst case response times meet the requirements or not. Traditional synchronization primitives use FIFO ordering among waiting threads to enter a critical section, since FIFO ordering can avoid starvation. In a real-time computing environment, however, FIFO ordering often creates a priority inversion problem[15]. A higher thread may have to wait for the completion of all low priority threads in the waiting queue. Real-time operating systems should support various synchronization policies based on two basic factors: one is a queueing order among waiting threads and the other is preemptability of the running thread in the critical section. 4.3

Base Object

Object Interface

Policy Interface

Figure 5: Policy/Mechanism Separation 4.4

Composition of Policy Modules via Inheritance

Creating new objects from existing objects is important when building complex systems. Our approach uses inheritance to composite policy objects as shown in Figure 6. Composite objects are created to de ne super classes. Messages to objects are forwarded to methods of suitable super classes. Each policy object has the same syntactic interface and has simple policies. Each policy should include only one policy and messages should be delegated to super classes. Complex policies can be created by inheriting several existing simple policies. In our scheme, controlling multiple inheritance is important for exible composition, but powerful mechanisms may make it dif cult to use by average programmers. The inheritance mechanisms for the composition should be customized for the purpose of systems. The mechanisms cannot be used in traditional object-oriented languages. We implement a special purpose run-time using C for the composition of scheduling policies.

Design Policies

In Real-Time Mach, we use two object-oriented techniques for the processor and the synchronization module. We present the design policies in the section. 4.3.1

Policy Object

Policy/Mechanism Separation

Real-time systems should support several policies for scheduling and synchronization. In Real-Time Mach, scheduler objects and lock objects are exported to users and policies should be selected by users. Operating systems control several resources such as CPU, memory, bus, and devices. Resource management policies such as processor scheduling, synchronization scheduling, memory scheduling, and communication scheduling are important for better resource managements. Traditional operating systems use a unique policy for scheduling, but in real-time systems it should be able to change these scheduling policies to ensure the requirements of users. The important issues lie in how the policies are binded and how the policies are called. In Real-Time Mach, scheduler and synchronization modules provide the interface which enable users to specify the policy of each object. We divide the objects into two parts. The rst part is the base object and the second part is policy object shown in Figure 5. Policy objects in each scheduling domain have the same syntactic interface so that base objects can change policies at any time. The policy objects are called from base object using procedure calls so that performance is not degraded.

4.5

Implementation of Scheduler

This section describes how one builds a exible scheduler in Real-Time Mach. 4.5.1

Structure of ITDS Scheduler

The ITDS scheduler provides an interface between the scheduler and the rest of the operating system. An objectoriented approach is used to implement the scheduler with the policies embedded in the policy object. Since Mach supports a multiprocessor environment, the ITDS scheduler allows a user to select a scheduling policy for each 5

ample, background threads in the rate monotonic scheduling policy can be scheduled by the xed priority, FIFO, or round-robin scheduling policy. If we create three dierent objects for each scheduling policy, most of the parts of Obj 5 Obj 4 the policies are will be redundant. If a programmer wants to create a new scheduling policy, he must create it from scratch. Obj 3 Obj 2 To solve the problem, we propose micro scheduling policy objects. Micro scheduling policy objects contain only simple scheduling policies such as xed priority, rateObj 1 monotonic, or deferrable server. A scheduling policy object which can be seen from the mechanism module consists of one or more micro scheduling policy objects. We use multiple inheritance for composition. A programmer can create a new scheduling policy through the composition of the micro scheduling policy objects by specifying its super classes. Consider the case when one Figure 6: Composition of Objects wants to create a scheduling policy C which is a composite of a real-time scheduling policy A and a non realtime scheduling policy B. We can create class C as a new scheduling policy by inheriting from the classes of policy A and policy B. The problem of our approach is the cost of the composition. The composition of micro scheduling policy objects requires several method calls to execute the routine in a policy interface. The scheduler is a critical component which aects system performance. In our implementation, we use a customized run-time for realizing multiple inheritance and method caches to make method calls faster. The scheduler need not change the con guration of the composition of policies unless current scheduling policy is changed. The method cache should be invalidated only at that time. The strategy reduces the overhead and impleFigure 7: ITDS Scheduler mentation cost, but needs a customized run-time which is not provided by traditional object-oriented languages. In the rate monotonic policy, we need only one procedure call processor. threads, and two procedure calls for aperiodic Figure 7 shows a block diagram of the ITDS scheduler for periodic 1. threads which indicates the relationship between the scheduler and policy objects. Micro Scheduling Policy Ob jects Interface object translates the functions of the sched- 4.5.3 uler interface to dispatch object. Dispatch object can be replaced for each target architecture, which forwards the The current version of RT-Mach supports 9 micro scheduloperation to an ITDS object attached to each processor. ing policy objects: round-robin (RR), fo (FIFO), xed-priority (FP), early deadline rst (EDF), rateDispatch object manages the control of preemption. An monotonic (RM)[10], deadline monotonic (DM), polling ITDS object forwards the operation to the current policy server (POLL), deferrable server (DS), and sporadic server object. (SS)[17], where POLL, DS and SS are aperiodic server policies. RM and DM can use DS or SS for sporadic 4.5.2 Scheduling Policy Ob jects threads and FP, FIFO or RR for background threads. From these objects, we support 28 scheduling policy obScheduling policies including background servers or apejects. riodic servers are becoming very complex. It is a very Now, we explain how to composite micro scheduling poldicult task to implement and add a new scheduling polMach Scheduler Interface

thread_block, choose_thread, thread_setrun

Interface Object

Dispatch Object

ITDS Policy Objects

RR

FP

ITDS Interface

RM

RMPOLL

RMDS

Policy Interface

ITDS Object

icy to a system. A policy may be very similar to other policies so that they may share portion of codes. For ex-

1 In

our implementation, the rate monotonic scheduling module

needs to call a background scheduling module.

6

SchedObj

Super Link

Mutex System Call Interface FIFO Super Link

Lock Policy Objects Super Link

Super Link

Lock Class

RM DS

Super Link

Object

BP

BPI

KM

PCP

Super Link

RMAPS

RR

SS

Lock Objects

Aps Link Super Link Back Link

RMRRSS

Figure 9: Lock Policy Module

Figure 8: Structure of Policy Module

ical section(RCS)[19]. These policies avoid the priority inversion problems, but have dierent preemption characteristics and cost. The synchronization module is divided into the lock class object, lock objects, and lock policy objects. Figure 9 shows the relationship between these objects. A lock class object is shared by all lock objects, which include the code of lock objects. Lock objects oer the mechanism to manage the blocking and unblocking of threads for exclusive access and lock policy objects manipulate the queues of threads waiting for the release of the lock according to the current processor scheduling policy. For synchronization, we do not need complex policy objects. Thus, we do not need the complex mechanism as in a processor scheduler.

icy objects using RMRRSS policy as an example. RMRRSS is a scheduling policy object where periodic threads are executed using a rate-monotonic scheduling and aperiodic threads are executed using sporadic servers. The aperiodic threads binding to the same sporadic server are scheduled in round-robin manner. We decompose a scheduling policy into a base scheduling policy, an aperiodic server policy, and a background scheduling policy. The classes of scheduling policy objects have three links to control multiple inheritance. An aps link indicates an aperiodic server policy, a back link indicates a background policy, and a super link represents a inherited scheduling policy by the current scheduling policy. A base scheduling policy controls scheduling of all tasks and it may call an aperiodic server policy object, a background policy object, and other policy objects through an aps link, a base link, and a super link. Figure 8 shows RMRRSS scheduling policy in our scheduler. RMAPS is a base scheduling policy which manages the rate monotonic scheduling policy as a base scheduling policy with arbitrary aperiodic server policies. In our framework, the inheritance mechanism is specialized for the scheduler to make it easy for users to create a new scheduling policy. The method cache is also specialized for simplifying the implementation. This framework cannot be supported directly by traditional objectoriented languages. 4.6

5

Implementation

of

System

Servers

We developed two experimental system servers using object-oriented techniques. The rst server is an object management server which provides le, device, and process objects. The server exports the interface to read, write, map, and execute objects. Second server is the communication server which enables objects to communicate with other objects in dierent sites. RPC is used to communicate between applications, servers and kernel (Figure 10). Each server is implemented using object-oriented techniques. The object management server manages system de ned objects such as le, device, process, and descriptor objects. All objects have the same syntactic interface. Objects may be inherited by other objects by inheritance. The framework enables the system to be con gured by adding, removing, and replacing classes according to the require-

Implementation of Synchronization

In our synchronization module, each synchronization policy module is implemented as an object. Currently, we provides several policy modules such as basic priority inheritance protocol(BPI), kernelized monitor(KM), priority ceiling protocol(PCP), restartable crit7

Application

Communication Server

Object Management Server

Device Object

TTY object

File Object

Net File Object

Process Object

Disk File Object

Object

Mach Kernel

Descriptor Object

Figure 10: System Servers

Figure 11: Structure of Object Management Server 6

ments of users. Currently, we implement three types of le objects; memory le, disk le, and network le objects. Memory le objects are volatile and stored only in memory. Disk le objects and network le objects are permanent and stored in local and remote disks. Disk le objects and network le objects are inherited from memory le objects. The noteworthy characteristics of our system is that we make descriptor objects rst class objects, which have the same syntactic interface as other objects. Clients of objects need not know whether the target object is a descriptor object or other object. Descriptor objects behave as lter to other objects. For example, it can check the permission of objects. Because descriptor objects are rst class objects, the functionalities of descriptor can be changed by the requirements of users like other types of objects. For example, access checking may not be required in an embedded system. To make descriptor object rst class objects, we support both inheritance and delegation in all objects which are used in the server. If a delegated object is speci ed, the message to the super class is forwarded to the delegated object not its superclass. The communication manager is implemented as an independent system server. We use x-kernel as the protocol interpreter for exible protocol management. RPC is used to send a message to the communication servers from applications. The ethernet driver is implemented in the servers as a user level device driver. The interrupts from the Ethernet board wakeup a thread which handles the interrupts and the thread does the traditional interrupt processing. The user level Ethernet driver reduce the communication between the server and kernels. Sending a message to networks requires several IPCs and context switching so that the cost is too expensive.

Discussion and Future Works

In this section, we discuss two issues which are important in microkernel based operating systems. The rst issue is the tradeo between exible structure and performance. The second issue is a language support to be used to implement operating systems. In traditional microkernel architectures, system servers use dierent address spaces to execute requests. Inside servers, we can use procedure calls to access objects. However, IPC is used to communicate between objects in different servers. IPC is expensive because IPC requires message copying and context switch between address space so that the decomposition of operating systems into multiple servers may lead to poor performance. In Mach3.0, traditional Unix is divided into applications, emulators, a Unix server, and a microkernel. Emulators reside in the same address spaces with applications. Unix system calls are forwarded to the emulators by the microkernel and emulators send requests to the Unix server using RPC. The execution of system calls requires several context switch and RPC. In table 1, we show the results of several benchmarks on Mach2.52 and Mach3.0 on an IBM AT compatible machine with a 16M Hz i386. Mach3.0 demonstrates that better structuring gives us

exibility, but requires much overhead. Anderson[1] shows that RPC and context switch of future CPU architectures will not be faster than integer performance. The results show that the structuring techniques using RPC do not become so fast in future. Object-oriented techniques based on procedure call are more appropriate in future operating systems. In Figure 12, we show the alternative architecture where 2 In

Mach2.5, all unix functionalities reside in kernel and do not

need extra context switches and RPC.

8

Mach 3.0 Mach 2.5

getpid(ms) 1.5 0.2

read 1M(Bytes/s) 174492 303056

write 1M(Bytes/s) 266136 397188

fork(ms) 80.7 50.8

IPC 1024/4096/8192(ms) 32.3: 68.0: 98.4 11.5: 23.5: 41.1

Table 1: Structuring Eect of Mach

Application 1

Application 2

gies, method caching policies, and memory management policies of memory allocation/deallocation and garbage collection. However, these powerful mechanism should be hidden from object designers. It is dicult to master excessively powerful and generic mechanisms and they are the cause of many errors. The object designers should use the restricted functions which is de ned by framework designers. These mechanism cannot be achieved by traditional object-oriented languages. Re ection[11] may solve the problem and provide a better framework for the design of system servers. A suitable level of openness is de ned by framework designers and object designer can create a new object in the servers without the risk of excessive powerful mechanism. The interaction of language/run-time supports and kernel supports will provide much better exibility and performance to users. Presently, we are designing the proposed architecture based on Real-Time Mach.

Application 3

System Server 1

System Server 2

Micro Kernel

Figure 12: Alternative Architecture system servers are mapped to each address space of an application. Each server has a private part and a shared part. The private part has a code, private data and stacks, and the shared part has global data which is necessary for all applications. The kernel should support the mechanism to call servers using much cheaper communication mechanism similar to LRPC[3]. Arguments are passed using stacks and we do not need the copy of the arguments. The mechanism is very cheap and make communication faster than traditional RPC. In each server, objects are called by procedure calls. The mechanism results in a two level abstraction. Run-time systems should hide the dierence and should provide uniform object model to programmers. Anderson[2] and Bershad[4] also show that run-time systems which reside in the same address space with applications are important to enhance performance and integration with languages. Flexible system servers can separate programmer into two levels. The rst of witch is the framework designers of the system servers and second is the object designer of servers. Framework designers decide the object model which is used in the system servers and object designers decide the design of objects which are used in the servers. Dierent servers may require dierent strategies for inheritance, semantics of method calls, and memory management policies. For framework designers, the system should provide powerful mechanism to de ne suitable object models for the servers. They should control inheritance strate-

7

Conclusion

We reported object-oriented techniques to be used in microkernel based operating systems. We show the structure of processor scheduler and synchronization module in Real-Time Mach and prototype system servers on Mach. Supporting multiple policies can be achieved by policy/mechanism separation and using policy objects. Also, composition of policies provides exible framework for creating complex policies. We also reported on the tradeo between exible structure and performance in microkernel based operating systems. We discuss two architectures and show objectoriented techniques are useful in these architectures and show the importance of the integration of language support and kernel. References [1] T.E.Anderson, H.M.Levy, B.N.Bershad and E.D.Lazowska, "The Interaction of Architecture and Operating System Design", In Proceedings of 4th International Conference on Architecture Support for Programming Languages and Operating Systems, 1991. [2] T.E.Anderson, B.N.Bershad, E.D.Lazowska and H.M.Levy, "Scheduler Activations: Eective Kernel

9

Support for the User-Level Management of Parallelism", In Proceedings of 13th Symposium on Operating System Principles, 1991.

[17] B. Sprunt, L. Sha and J. P.Lehoczky, "Aperiodic Task Scheduling for Hard-Real-Time Systems", The Journal of Real-Time Systems, Vol.1, No.1, 1989.

[3] B.Bershad, T.Anderson, E.Lazowska, and H.Levy, "Lightweight Remote Procedure Call", ACM Transaction on Computer Systems, Vol.8, No.1, 1990.

[18] H. Tokuda, T. Nakajima, and P. Rao, "Real-Time Mach: Towards a Predictable Real-Time System", In Proceedings of USENIX Mach Workshop, October, 1990.

[4] B.N.Bershad, T.E.Anderson, E.D.Lazowska and H.M.Levy, "User-level Interprocess Communication for Shared Memory Multiprocessors", ACM Transaction on Computer Systems, Vol.9, No.2, 1991.

[19] H. Tokuda and T. Nakajima, "Evaluation of Real-Time Synchronization in Real-Time Mach", In Proceeding of USENIX 2nd Mach Symposium 1991.

[5] D. Golub, R. Dean, A. Forin, and R. Rashid, "Unix as an application program", In the proceedings of Summer Usenix Conference, June, 1990. [6] J.S.Heidemann and G.P.Popek, "A Layered Approach to File System Development", University of California, Los Angeles, Technical Report, CSD-910007, 1991. [7] N. Hutchinson and L. Peterson "The x-Kernel: An Architecture for Implementing Network Protocols", IEEE Transactions on Software Engineering, Vol.17, No.1 1991. [8] S.J.Leer, M.K.McKusick, M.J.Karels and J.S.Quarterman, "The Design and Implementation of the 4.3BSD UNIX Operating System", Addison Wesley, 1989. [9] R.Lea, P.Amaral and C.Jacquemot, "COOL-2: An Object Oriented Support Platform built above the Chorus Micro-kernel", In Proceeding of 2nd IWOOOS, 1991. [10] C. L. Liu and J. W. Layland, "Scheduling algorithms for multiprogramming in a hard real time environment", Journal of the ACM, Vol.20, No.1, 1973. [11] P.Meas, "Concepts and Experiments in Computational Re ection", In Proceedings of OOPSLA'87, 1987. [12] D.M.Richie, "A Stream Input-Output System", AT&T Bell Laboratories Technical Journal, 63(8), 1984 [13] M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemount, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser, "Chorus Distributed Operating System", Computing Systems Journal, The Usenix Association, December, 1988 [14] V.F.Russo, "An Object-Oriented Operating System", Ph.D Thesis, University of Illinois at Urbana-Champaign. [15] L.Sha, R.Rajkumar, and J.P. Lehoczky, "Priority inheritance protocols: An approach to real-time synchronization", Technical Report CMU-CS-87-181, Carnegie Mellon University, November 1987 [16] M.Shapiro, Y.Gautron, S.Habert, L.Mosseri, M.Run and C.Valot, "SOS: An Object-Oriented Operating System - Assessment and Perspectives", Computing Systems, Vol.2, No.4, 1989.

10

[20] H.Tokuda and T.Nakajima "Design and Implementation of Real-Time Scheduler in Real-Time Mach", In preparation. [21] B.B.Welch, "Naming, State Management, and UserLevel Extensions in the Sprite Distributed File System", University of California Berkeley, Technical Report UCB/CSD 90/567 1990.