Systems and Computers in Japan Volume 33 Issue 10 2002Masahito Shiba; Eiji Okubo -- Design and...

8/10/2019 Systems and Computers in Japan Volume 33 Issue 10 2002Masahito Shiba; Eiji Okubo -- Design and Implementation of the Solelc Distributed Operating System

1/10

Design and Implementation of the Solelc Distributed

Operating System

Masahito Shiba1and Eiji Okubo

2

1Graduate School of Science and Engineering, Ritsumeikan University, Kusatsu, 525-8577 Japan

2Department of Computer Science, Faculty of Science and Engineering, Ritsumeikan University, Kusatsu, 525-8577 Japan

SUMMARY

In order to efficiently use multiple computers on a

network, resource management that takes all those comput-

ers into account is desirable. However, the resources that

each conventional operating system manages are limited to

those of the computer on which it works. By making the

operating system itself work in a location-transparent fash-

ion, it becomes possible to manage all resources on multiple

computers with a single operating system. In this paper, we

propose an abstraction method for location-transparent

management of computer resources such as memory,

CPUs, interrupts, and peripheral devices. The structure and

performance evaluations of the Solelc distributed operating

system, which is based on this method, are described.

2002 Wiley Periodicals, Inc. Syst Comp Jpn, 33(10):

5463, 2002; Published online in Wiley InterScience

(www.interscience.wiley.com). DOI 10.1002/scj.10011

Key words: operating system; distributed system;

resource management; memory management.

1. Introduction

With the spread of low-cost computers and high-

speed networks, it is increasingly common to use distrib-

uted systems which have many computers connected by

networks. However, in conventional distributed systems,

each operating system manages only the resources of the

computer on which it works. Therefore, even when a system

includes more than one computer, the resource manage-

ment of the system is performed on each computer, and it

is difficult to realize resource management that takes ac-

count of the whole system.

In order to solve this problem, based on our knowl-

edge of operating system development [1], we have been

investigating an abstraction method for managing resources

with location transparency. When location transparency ofresource management has been realized, a single kernel can

manage resources on more than one computer. As a result,

resource management that takes the whole system into

account is achieved. In this paper, we propose a new method

of construction of a distributed operating system that man-

ages multiple computers in this manner. The structure of the

Solelc distributed operating system [2, 3], which is based

on the proposed method, is also described. Furthermore,

performance evaluation of Solelc confirms that efficient

and location-transparent resource management is achieved

by the proposed method.

In Solelc, since the kernel itself works location-trans-parently, the single kernel can manage all computers col-

lectively and thus the kernel takes account of and manages

the whole system. Furthermore, this method unifies the

control data for resource management and simplifies the

structure and behavior of the kernel. In other words, the

kernel can manage resources on more than one computer

by a method similar to that used in conventional kernels that

2002 Wiley Periodicals, Inc.

Systems and Computers in Japan, Vol. 33, No. 10, 2002Translated from Denshi Joho Tsushin Gakkai Ronbunshi, Vol. J84-D-I, No. 6, June 2001, pp. 617626

54


2/10

manage a single computer. This method has the following

advantages:

The kernel is enabled to manage peripheral de-

vices with location transparency.

The same environment for process execution is

created on all computers.

Dynamic addition (deletion) of computers to

(from) the system is realized.

Since device locations do not restrict the behavior of

the kernel, it is, for example, easy to build a file system on

two or more disks of different computers. When a new

computer is added to the system, the kernel and processes

can use the resources of this computer as well as the

resources of other computers, because it is possible for the

kernel and processes to use the resources of any computers

with location transparency. Therefore, the computing per-

formance of the system would be improved easily by add-

ing computers to the system.

This paper describes the structure of Solelc in Section

2, memory management in Section 3, process and threadmanagement in Section 4, event management in Section 5,

and device management in Section 6. The effectiveness of

the proposed method is described with performance evalu-

ation in Section 7 and related research is discussed in

Section 8.

2. Structure of Solelc

Figure 1 shows the overall structure of Solelc. In

Solelc, the operating system consists of abstraction layers

and a kernel. The abstraction layers work on each computer,and the abstraction layers provide the environment on

which the kernel works. The kernel uses functions provided

by the abstraction layers and manages the resources of all

computers. Furthermore, the kernel builds the execution

environment for processes and allocates the resources of the

system to processes appropriately. In the rest of this section,

these components of Solelc are described.

2.1. Abstraction layer

The abstraction layers abstract memory, CPUs, inter-

rupts, and peripheral devices. The abstraction layers have

the following functions.

Memory management

Construct an address space shared with all comput-

ers.

CPU management

Abstract CPUs as threads. The threads execute codes

of the kernel or processes.

Interrupt management

An interrupt is abstracted as events, which the kernel

can detect on any computer.

Device management

Manipulate peripheral devices with device drivers

and allow the kernel to use the functions of all device driversfrom any computers.

Communication facility

Abstraction layers have facilities for communication

with each other.

Device drivers

Each device driver controls peripheral devices.

Table 1 shows the number of source code lines of

these functions. The size of the abstraction layer is 44K

bytes.

Furthermore, by the following functions, the abstrac-

tion layers build an environment in which the kernel canmanage resources location-transparently.

The abstraction layers assign identifiers to com-

puters and available resources. An identifier is a

unique nonnegative integer value.

When an abstraction layer gets a resource manipu-

lation request from the kernel, the abstraction

Fig. 1. Overall structure of Solelc.

Table 1. Number of source code lines

55


3/10

layer forwards this request to the abstraction layer

that has the target resource.

When resource management is performed on each

computer, complicated name management, such as using a

name server, is needed. In Solelc, it is possible to identify

each resource solely by a nonnegative integer value, since

a single kernel manages all resources. The abstraction lay-

ers use a dedicated network protocol for communication

with each other, which realizes efficient cooperative work.

On the other hand, the kernel uses network protocols such

as IP for communication with systems other than Solelc.

The kernel manages resources by using interfaces

(see Table 2) which the abstraction layers provide. The

method of resource management in Solelc is described in

detail in Section 3.

2.2. The kernel

In Solelc, the kernel plays the same role as the kernels

of conventional systems. However, it is different from con-

ventional systems in that the kernel in Solelc operates in an

environment provided by the abstraction layers and man-

ages multiple computers simultaneously.

The code of the kernel is executed by one or more

kernel threads. Since a kernel thread works with the func-

tions of abstraction layers, the behavior of the kernel thread

does not depend on its own location or the resource loca-

tions, and the kernel thread can always work in the same

manner. Since kernel threads work in location-transparent

fashion, it is possible to have each thread work on a different

computer and to dynamically change the computer on

which a thread runs.

In Solelc, the single kernel manages more than one

computer. In conventional systems, a kernel runs on each

computer and the resource management and services are

provided by the cooperative work of those kernels; thus,

cooperative work among computers cannot be avoided.

Cooperative work of kernels gives rise to the problem that

kernel behavior becomes complicated. However, in Solelc,

the behavior of the kernel is simple since the single kernel

manages all computers.

2.3. Processes

Processes run in an environment built by the kernel

and use the facilities of the kernel. More than one process

can run simultaneously, and all processes are protected

from each other. That is, the processes of Solelc are the same

as those of conventional systems.

In Solelc, a process has one or more user threads, and

these threads execute the code of the process. Each user

thread is able to access code and data of the process to which

it belongs on any computer, and runs location-transparently.

Therefore, it is possible to change the computer on which

a thread runs without affecting the action of the thread. It is

easy to implement a mechanism for load balancing by

utilizing this feature [4].

3. Memory Management

3.1. Address space

Figure 2 shows the virtual address space of Solelc.

The virtual address space consists of two regions: a non-

shared region and a shared region. Each nonshared region

has an abstraction layer, and each computer has different

memory contents in this region. On the other hand, the

shared region has the kernel and processes, and all comput-

ers have the same memory contents in this region.

The code of an abstraction layer, which is placed in

the nonshared region, includes interrupt handlers and facili-ties for communication with other computers. Furthermore,

the data of an abstraction layer include data for managing

the address space and threads. This code and data must

Table 2. Interface of abstraction layer

Fig. 2. Structure of address space.

56


4/10

always be accessible and thus the regions that contain this

code or data are always allocated physical memory pages.

On the other hand, the shared region is shared by all

computers, and virtual memory pages in this region are

mapped into physical memory pages of the computers that

actually use these pages. The abstraction layers maintain

consistency of memory contents in pages that two or more

computers access simultaneously. That is, the abstraction

layers detect page faults of the kernel and processes, and

perform consistency control of the shared region. The con-

sistency that abstraction layers provide as the memory

consistency model is sequential consistency [5]. Therefore,

the kernel and processes can access memory without being

concerned with consistency control.

3.2. Segment

The shared region consists of a kernel region and a

user region. The kernel region contains code and data of the

kernel, and the user region contains processes. Manage-

ment of these regions is performed by the kernel. That is,

the kernel divides the user region into multiple segments

and assigns each segment to a process. A segment is a

sequential memory area that has the same protection attrib-

ute, and segments are created by setting the MMU (Memory

Management Unit) appropriately. By assigning each seg-

ment to a process, other processes and the operating system

are protected from illegal operations by the process. In

Solelc, all computers share not only the contents of memory

but also the protection attributes of memory.

All segments are registered into a segment table and

maintained by this table. The abstraction layers provide the

kernel with the following functions to manipulate the seg-

ment table.

segment_set(index, base, size)

Register a segment whose base address is baseand

whose size is sizebytes into the indexthentry of the segment

table.

The following is the processing flow when the kernel

sets up a segment with segment_set(see Fig. 3).

(1) The kernel requires an abstraction layer to set up

a segment with segment_set.

(2) The abstraction layer that has received the request

reports index, base, and size to all abstraction layers on

other computers.

(3) Each abstraction layer sets up the segment of the

computer on which it runs.

(4) It is reported to the kernel that the setting up of

the segment has completed.

The abstraction layer that has received a request from

the kernel reports it to all other computers, and all abstrac-

tion layers set up the segment. As a result, the protection

attributes of memory are kept the same on all computers.

4. Process and Thread Management

4.1. The process

Solelc executes user programs with the process

thread model. A process, which consists of code and data,is the execution environment of threads. The substance of

a process is data in memory. All processes should be avail-

able on all computers, since processes are in the shared

region. Therefore, by placing the data and code of a pro-

gram on only one computer, the kernel is able to create a

process which is available on all computers. Thus, it is

possible for the kernel to manage processes in a location-

transparent manner.

4.2. Threads

Threads are used for executing code in the shared

region, and are classified into two types: user threads and

kernel threads. User threads execute the code of processes

and kernel threads execute the code of the kernel. Kernel

threads can access all memory in the shared region. On the

other hand, a user thread can access only the memory of the

process to which it belongs. A process can have one or more

threads, and threads that belong to the same process can run

on different computers.

Threads are an abstraction of CPUs. Abstraction lay-

ers manage threads with thread control data possessed by

the abstraction layers. The thread control data are shown in

Table 3. idis a nonnegative integer value, assigned by the

abstraction layers. ids are used for uniquely identifyingeach thread. hostis the identifier of the computer to which

the thread is assigned, and the thread runs by using the CPU

of the assigned computer. The running state, ready state,

and waiting state are the states of threads, as in conventional

operating systems. A state transition of a thread is per-

formed by the abstraction layer that manages the computer

on which the thread runs. For example, an abstraction layer

Fig. 3. Setting up a segment.

57


5/10

chooses a thread with the highest priority among the ready-

state threads, changes the state of this thread to running

state, and executes this thread. Thus, each abstraction layer

functions as a dispatcher in the thread management.

On the other hand, the kernel works as a scheduler,

which determines the priorities of the threads and the com-

puters to which the threads are assigned. It is possible to use

the resources of the system efficiently by assigning a newly

created thread to a computer that has an idle CPU or by

assigning a thread that frequently accesses a device to a

computer that has this device. Furthermore, the kernel has

data for managing parent-child relationships of threads and

relationships among processes and threads. It is possible for

the kernel to manage these data in unified fashion, since

only one kernel manages the whole system.

Although abstraction layers store and manipulate

thread control data, the kernel can manipulate thread con-

trol data by using the following functions, which abstrac-

tion layers provide.

thread_create(thread)

Create a new thread and get thread control data of this

thread into thread.

thread_set(thread)Set threadto the thread control data.

thread_get(id, thread)

Load the thread control data whose identifier is idinto

thread.

thread_create creates a new thread and gives it an

identifier that is unique in the whole system. The kernel sets

up register, state, priority, and hostof the thread control

data of the new thread created by thread_create, and the

kernel sets these data into the abstraction layer by using

thread_set. If the state of this thread is the ready state, the

abstraction layer inserts it into the ready queue and it willbe executed. Furthermore, the kernel can change the thread

control data of any thread by using thread_get and

thread_set. In these operations, the kernel specifies only the

thread identifier. Thus, the kernel manipulates threads re-

gardless of the locations where the threads are actually

running. This is because an abstraction layer that receives

thread_setor thread_getchecks hostin the thread control

data and forwards the thread control data to the abstraction

layer that manages the thread. In this way, the kernel is also

location-transparent in thread management.

4.3. Creation of process and thread

In Fig. 4, Process-A creates Process-B. The process-

ing flow of creating a process and a thread is as follows.

(1) The kernel receives aforksystem call from Proc-

ess-A.

(2) The kernel prepares a memory region for Process-

B and copies the memory contents of Process-A to this

region.

(3) The kernel requires an abstraction layer to create

a new thread by thread_create.

(4) The abstraction layers create a new thread and

give the thread control data of this thread to the kernel.

(5) The kernel sets the parameters of the thread con-

trol data and requires the abstraction layers to set this thread

control data by thread_set.

(6) The abstraction layer that has received the requestsends the thread control data to the computer that is to

manage this thread.

(7) The abstraction layer that has received the thread

control data executes the new thread.

In (5), the kernel determines the computer on which

the new thread will run, and sets hostof the thread control

data as the identifier of this computer. The abstraction layer

that has received the thread control data determines the

computer on which the thread is to run from host, and

forwards the thread control data to this computer. Although

the memory copy operation to create Process-B is per-formed on the computer that processes theforksystem call,

the memory contents are available on other computers since

processes are placed in the shared region, which all com-

puters share. Therefore, the thread can run Process-B on the

forwarded computer by forwarding only the thread control

data.

In this way, since abstraction layers forward kernel

requests to the appropriate computers, the kernel always

Table 3. Thread control data

Fig. 4. Creation of a process and a thread.

58


6/10

manipulates threads in the same manner, which does not

depend on the locations of the threads. The same is true of

thread migrations between computers for load balancing.

The kernel causes threads to migrate by changing hostin

the thread control data. At this time, the kernel specifies

only the identifier of the computer to which the thread

migrates, and this processing is independent of the physical

locations of the computers.

5. Event Management

5.1. Events

In Solelc, the abstraction layers abstract asynchro-

nously arising phenomena as events and notify the kernel.

Examples of events are internal interrupts or the addition of

a new computer to the system. The kernel receives events,

handles them, and then manages the whole system. This is

similar to the procedure in conventional systems by which

a kernel detects interrupts and manages the system.

Each event has an event number, which is a nonnega-tive integer value and is unique to one kind of event. The

kernel can receive events having the specified event number

by using the following two functions, which the abstraction

layers provide.

event_set_receiver(event, id)

event_set_receiver sets the identifier of a receiver

thread to id. This thread is then enabled to receive events

that have eventas event number.

event_receive(event, thread)

event_receive receives an event and sets the event

number in eventand the thread control data of the thread

which caused the event in thread.

The kernel performs advance registration of threads

that are to receive events into abstraction layers by

event_set_receiver. The abstraction layer that has been

requested to perform event_set_receiverreports this request

to all abstraction layers. After registration of the receiver

thread, the abstraction layers forward the event when it

occurs on any computer to the computer on which the

thread for acquiring it is running. Therefore, it is possible

for the kernel to acquire all events which occur on any

computer. The receiver threads receive events with

event_receive. A receiver thread that has requested

event_receiveenters the waiting state, and when the eventoccurs, the receiver thread resumes and acquires the event.

Figure 5 shows that events occur on each computer

and that the abstraction layers forward these to the kernel.

The abstraction layers manage events by placing them on

event queues, which exist for every event number. The

abstraction layer that has been requested to perform

event_receive by a receiver thread takes an event off the

event queue and passes this event to this receiver thread. At

this time, the thread control data of the thread that has

caused the event are also passed to the receiver thread. In

Solelc, events may occur during event handling because

two or more computers are running simultaneously. How-

ever, when an event occurs, the event does not immediately

interrupt the action of the kernel, but is placed in the event

queue by the abstraction layers. Therefore, it is possible forthe kernel to handle events successively.

5.2. System calls

By acquiring events, the kernel detects internal inter-

rupts caused by threads in the course of their operation.

Thus, the kernel can acquire errors such as zero division or

protection violations caused by threads, and handle these.

The kernel also provides the system call mechanism as

follows.

(1) The kernel registers the threads that receive sys-

tem call events into the abstraction layers by event_set_re-

ceiver.

(2) The receiver thread requests receipt of an event

by event_receive.

(3) A user thread sets the system call number and

arguments in the CPU registers and causes the internal

interrupt.

(4) An abstraction layer that has received the interrupt

changes the state of the user thread to the waiting state.

Furthermore, the abstraction layer sends the event number

and the thread control data to the computer on which the

receiver thread is running.

(5) The event is passed to the receiver thread, and the

kernel handles the system call.

The thread that has requested receipt of an event

enters the waiting state at (2), and resumes at (5). The

receiver thread gets the system call number and arguments

from registerin the thread control data that it receives. In

this way, both user threads that request system calls and

kernel threads that receive and handle these calls work

Fig. 5. Event management.

59


7/10

without depending on each others location, since the ab-

straction layers abstract internal interrupts as events.

6. Device Management

6.1. Peripheral devices

In Solelc, peripheral devices such as disks or key-

boards are abstracted by device drivers in the abstractionlayers. The device drivers have facilities which directly

control devices and manipulate the devices according to the

interrupts received. The abstraction layers manage the de-

vice drivers and provide the kernel with functions to use

them. The kernel uses the device drivers with the device

management interfaces shown in Table 2.

Abstraction layers create device lists. Each abstrac-

tion layer has a device list, which contains information on

all available devices on any computers. A device list con-

sists of records holding the identifier of the device, type of

the device, and the identifier of the computer which has the

device. The kernel can get the device list from the abstrac-tion layers and determine the identifier and type of each

device from the device list. When the kernel uses a device,

the kernel requests from an abstraction layer the operation

of the device with the given device identifier. The abstrac-

tion layer that has received the request from the kernel

forwards this request to the computer that has the specified

device. In addition, the device driver result is returned to

the abstraction layer and is passed to the kernel. Therefore,

the kernel specifies only device identifiers, which are loca-

tion-independent. In other words, the kernel manages de-

vices with location transparency and the kernel can manage

all devices on arbitrary computers.

6.2. File system

A file system is one of the services that the kernel

provides by using devices. Figure 6 shows a user thread that

requests a file read, a kernel thread that provides the file

service, and a device driver that manipulates the disk, which

operate without depending on each others locations. The

flow of reading a file from a disk is as follows.

(1) The user thread requests a file read by a system

call.

(2) The kernel thread requests the reading of block

data from the disk.(3) The abstraction layer forwards the request from

the kernel to the computer that has the target disk.

(4) The abstraction layer that has received the for-

warded request calls the device driver and reads block data

from the disk.

(5) The block data are returned to the abstraction

layer and passed to the kernel.

(6) The kernel thread puts the file data into the buffer

that the user thread specifies.

Abstraction layers manage device locations, and for-

ward both requests from the kernel and results from device

drivers to appropriate computers. Therefore, the kernel can

read block data from the disk by specifying only the iden-

tifier of the device. Furthermore, since abstraction layersprovide memory consistency among computers, the kernel

thread writes file data to a buffer on a computer and the user

thread can read these file data on another computer.

In Solelc, since the kernel manages devices inde-

pendently of their locations, the kernel can easily provide

services that are difficult to realize in conventional systems.

For example, it is easy to build one file system on two or

more disks, not only on one computer, but also on different

computers. In addition, it is possible to build one terminal

with a keyboard and a display that are on different comput-

ers, as well as on the same computer. Furthermore, it is

possible to build one terminal with multiple keyboards and

multiple displays.

7. Evaluation

It is required in Solelc only that the kernel have the

same facilities as conventional systems that manage a single

computer. The kernel in Solelc has facilities and interfaces

like those that UNIX kernels provide. In this section, the

performance evaluations of the system call facility and file

read operations with the getpidand readsystem calls are

described.

The computers used in the experiments had the same

architecture. Concretely, PC/AT-compatible computers

with a Pentium 200MHz CPU, connected via a 100Mbps

Ethernet, were used. The processes used for the evaluations

were linked with glibc-2.1.3 [6] complied for Linux.

Fig. 6. Reading a file from a disk.

60


8/10

7.1. System call

Table 4 shows the execution times when a user thread

requests the getpidsystem call and a kernel thread performs

processing for this. The following two cases were evalu-

ated.

(1) The user thread and the kernel thread run on the

same computer.

(2) The user thread and the kernel thread run on

different computers.

Although the user thread and the kernel thread per-

form the same processing in both cases, communications

between abstraction layers occur in (2) and thus the execu-

tion time of (2) is longer than that of (1). The following

communications occurred in (2): forwarding of events, and

forwarding of thread control data when the state of the user

thread is changed to the ready state after completion of the

system call processing. For execution of the kernel thread,

(2) needs 93.3 s, which is longer than the 11.3 s needed

in (1). This is because (2) consumes 66.8 s in waiting for

a response after sending the thread control data. It can be

said that this time depends more on the performance of

network applications than on the structure of the operating

system. Furthermore, since other ready threads can run

while the kernel thread is waiting, the execution time that

the kernel thread actually needs is 93.3 66.8 = 26.5 s.

Therefore, it is concluded that the difference between this

time and the kernel execution time in (1), 26.5 11.3 = 15.2

s, is the overhead time when the kernel thread handles a

system call from a user thread running on another computer.

There are two kinds of processing in a system call.

One is the performance of the requested system call and

changing the state of the user thread to the ready state. The

other is preparation for receiving the next system callrequest. In case (1), the user thread cannot run until the

kernel thread completes these two kinds of processing,

since the priority of the user thread is lower than that of the

kernel threads. In case (2), the user thread can run immedi-

ately after completion of processing of the system call,

since the user thread runs on a computer that is different

from that on which the kernel thread runs.

7.2. Reading a file

Figure 7 shows the execution times when a user

thread reads the contents of a file to a buffer with the read

system call. The format of the file system is Ext2fs [7]. In

reading a file, the following three components run concur-

rently: a user thread which requests the system call, a kernel

thread which provides file service, and a device driverwhich manipulates a disk. The following four cases were

evaluated in order to examine the changes of execution

times as a function of the locations of these three compo-

nents.

(1) The user thread, the kernel thread, and the device

driver run on the same computer.

(2) The user thread and the kernel thread run on the

same computer, and the device driver runs on another

computer.

(3) The kernel thread and the device driver run on the

same computer, and the user thread runs on another com-

puter.

(4) The user thread, the kernel thread, and the device

driver all run on different computers.

Since the user thread, the kernel thread, and device

driver run in a location-transparent manner, these three

components run in the same way in the above four cases.

However, communications occur among abstraction layers

except in (1).

In (1), the execution time becomes longer whenever

the read size increases by 1024 bytes. This is because the

kernel thread reads 1024 bytes at a time via the device

driver. Therefore, whenever the read size increases by 1024bytes, the number of calls to the device driver increases, and

the execution time becomes longer. In (2), communications

between abstraction layers occur, since the kernel thread

and the device driver called by the kernel thread are running

on different computers. Therefore, the increase in execution

time caused by an increase in the number of calls to the

device driver is longer than in (1).

Fig. 7. Execution time of read.

Table 4. Execution time of getpid

61


9/10

In (3), since the user thread and the kernel thread run

on different computers, communications occur for memory

consistency control, and for forwarding the event and the

thread control data. The communications for memory con-

sistency control at this time consist of sending and receiving

memory pages of the read buffer prepared by the user thread

when the kernel thread writes contents of the file into the

buffer. The execution times are 2.02 ms in (1) and 2.64 ms

in (3) for a read size of 4096 bytes. The difference of these,2.64 2.02 = 0.62 ms, is regarded as the time required for

memory consistency control. When the read size is 8129

bytes, the difference of execution times between (1) and (3)

is 1.04 ms. This time is longer than when the read size is

4096 bytes. This is because consistency control is per-

formed per memory page, whose size is 4096 bytes. There-

fore, the execution time increases greatly whenever the read

size increases by 4096 bytes.

In both (2) and (3), the user thread reads from a disk

on a different computer. Although the abstraction layers

transfer memory pages for memory consistency control in

(3) and do not perform this action in (2), the execution timesin (3) are close to those in (2) on the whole. This is because

unnecessary transfer of memory pages is not performed.

The user thread accesses the read buffer after completion of

the readsystem call. That is, the kernel thread and the user

thread access the buffer, which is shared by the kernel

thread and the user thread in that order. The kernel thread

and the user thread do not access the buffer simultaneously.

Therefore, overhead is not a serious problem even if con-

sistency control for sequential consistency is performed.

In (4), the communications in both (2) and (3) occur.

The execution time increases greatly whenever the read size

increases by both 1024 and 4096 bytes. When the system

consists of multiple computers, because disks are the dis-

tributed on multiple computers, it is not rare that a user

thread reads from a disk on a different computer, as in (4).

In such case, it is possible that a kernel may handle read

requests in the form of (2) or (3) if it can operate in

location-transparent fashion like Solelc. In other words, it

can be said that a kernel that operates in location-transpar-

ent fashion achieves efficient resource management. Fur-

thermore, consistency control of the file management

information which each computer maintains is needed if

requests for file operations are handled on each computer.

In Solelc, it is possible that all requests of file operations

from multiple computers are handled on a single computer,

since the kernel works in a location-transparent fashion.

Therefore, communications for maintaining the consis-

tency of file management information do not occur, and it

is possible to handle requests efficiently even if multiple

requests occur simultaneously.

8. Related Research

There are various ways to provide processes with a

location-transparent environment. For example, Java Re-

mote Method Invocation and CORBA [8] provide proc-

esses with facilities to use remote objects. Many such

systems realize location transparency on the user level. On

the other hand, there are sockets in UNIX and ports in Mach

[9], which realize location transparency on the kernel level.

By using these facilities, processes can always exchange

messages with each other in the same manner without

depending on their locations. Furthermore, in distributed

operating systems such as Amoeba [10] and Chorus [11],

processes can use not only message communication but

also many facilities for providing processes with location

transparency. For example, each CPU is not bound to a

specific user, and it is possible to use an arbitrary CPU for

execution of a process. Furthermore, processes can make

location-transparent use of services provided by servers

such as file servers. In Solelc, as in these systems, processescan use system facilities in a location-transparent manner.

Furthermore, the kernel itself, which manages resources,

functions in a location-transparent manner in Solelc. There-

fore, it is possible for a single kernel to manage the re-

sources of all computers regardless of their locations. That

is, it can be said that conventional systems that manage one

computer are enabled to operate in a distributed environ-

ment by abstraction of resources.

In Solelc, the operating system is layered for loca-

tion-transparent resource management. Many operating

systems are also layered. For example, Windows NT [12]

has a Hardware Abstraction Layer, which abstracts thehardware. By layering an operating system, it is possible to

separate hardware-dependent components and to encapsu-

late hardware-specific components. Furthermore, in Solelc,

abstraction layers also encapsulate a network. Therefore,

the upper layers are not bound to the locations of computer

resources.

In Solelc, a single address space is shared by all

computers. Various memory consistency controls have been

proposed for distributed shared memory, which enables two

or more computers to share memory objects. Many of these

memory consistency controls provide weak consistency. In

these systems, processes which know a feature of shared

data are directly concerned with consistency control in

order to enhance performance. On the other hand, in Solelc,

abstraction layers provide sequential consistency and the

kernel and processes do not need to be concerned with

consistency control. In addition, there is the advantage that

not only data but also code can be shared by all computers.

62


10/10

9. Conclusions

This paper has proposed a method for abstraction of

computer resources and management of computers by a

single kernel with location transparency, and has presented

performance evaluations of the Solelc distributed operating

system, which is based on the proposed method. Further-

more, it has been shown that efficient resource management

is realized by the location-transparency provided by ab-

stract layers.

Currently, we are investigating the efficiency,

scalability, and fault tolerance of the system.

REFERENCES

1. Shiba M, Okubo E. An abstraction scheme of com-

puter resources for the location transparent resource

management. Special Interest Group Report 2000-

OS-83. Inf Process Soc Japan 2000, No. 21, p 6772.

2. Shiba M, Okubo E. The structure of Solelc distributed

operating system. Special Interest Group Report2000-OS-84. Inf Process Soc Japan 2000, No. 43, p

237244.

3. Mizuguchi T, Shiba M, Okubo E. The design and

implementation of file system on distributed operat-

ing system Solelc. Inf Process Soc Japan 2000, No.

43, p 245252.

4. Nagamune K, Shiba M, Okubo E. The load sharing

mechanism in Solelc distributed operating system.

Inf Process Soc Japan 2000, No. 75, p 3946.

5. Lamport L. How to make a multiprocessor computer

that correctly executes multiprocess programs. IEEE

Trans Comput 1979;C-28:690691.

6. gl ibc source, f tp: / /sourceware.cygnus.com/

pub/glibc/releases/glibc-2.1.3.tar.bz2.

7. Ext2fs Home Page. http://web.mit.edu/tytso/www/

linux/ext2.html.

8. CORBA Website. http://www.corba.org/.

9. Accetta M, Baron R, Golub D, Rashid R, Tevanian

A, Young M. Mach: A new kernel foundation for

UNIX development. Proc Summer 1986 USENIX, p

93113.

10. Mullender SJ, van Rossum G, Tanenbaum AS, van

Renesse R, van Staveren H. Amoeba: A distributed

operating system for the 1990s. IEEE Comput

1990;23:4453.

11. Rozier M, Abrossimov V, Armand F, Boule I, GienM, Guillemont M, Herrmann F, Kaiser C, Langlois

S, Leonard P, Neuhauser W. CHORUS distributed

operating systems. Comput Syst 1988;1:305370.

12. Custer H. Inside Windows NT. Microsoft Press; 1993.

AUTHORS(from left to right)

Masahito Shibareceived his B.E. degree from the Department of Computer Science of Ritsumeikan University in 1997

and his M.E. degree in 1999. He is presently a D.Eng. candidate there. His research interests include operating system, distributed

system, and real-time system. He is a member of the Information Processing Society of Japan and IEICE.

Eiji Okuboreceived his B.S. degree from the Department of Mathematics of Hokkaido University in 1974 and his M.S.

degree in 1977. He then joined the Software Factory of Hitachi, Ltd., and was mainly engaged in development of FORTRAN

compiler. He moved to Kyoto University in 1979, becoming a lecturer in 1985 and an assistant professor in 1987. He has been

a professor in the Department of Computer Science of Ritsumeikan University since 1991. He has engaged in the study of

operating system, database system, distributed system, and real-time system, among others. He holds a D.Eng. degree. He is

the author ofBasics of Operating System(Saiensu Press) and a coauthor ofBasics of Modern Operating System, Experiment

of Information Engineering, and Introduction to Information Processing(Ohm Press). He is a member of the Information

Processing Society of Japan, the Japan Society for Software Science and Technology, the Institute of System Control and

Information Engineers, ACM, and IEEE-CS.

63

Systems and Computers in Japan Volume 33 Issue 10 2002Masahito Shiba; Eiji Okubo -- Design and...

Documents

Transcript of Systems and Computers in Japan Volume 33 Issue 10 2002Masahito Shiba; Eiji Okubo -- Design and...