Evaluation of Exchanging Time for Mechanism of Exchanging

Parts of Programs during Execution

Hideo Taniguchi and Masataka Goto

Graduate School of Information Science and Electrical Engineering, Kyushu University, Fukuoka, 812-8581 Japan

SUMMARY

The authors describe the relationship with program

characteristics for a method of exchanging the parts of a

program during execution. They then formulate the ex-

changing time and the thread stoppage time during which

the thread is stopped so it can be exchanged. In application

programs that share execution units (threads) allocated in a

processor or in the case of operating system programs that

can be preempted, parts of several programs must be ex-

changed at the same time. These program parts are shared

among many threads. The exchanging time rises along with

the processing time for the program part to be exchanged,

and the impact on the number of threads which a program

shares is minimal. The thread stoppage time during

which a thread is stopped so it can be exchanged rises

along with the number of shared threads and the process-

ing time for the program parts to be exchanged. The

formulation for the exchanging time and the thread stop-

page time is shown to have results similar to real meas-

urements. © 2001 Scripta Technica, Syst Comp Jpn,

32(8): 53�62, 2001

Key words: Reliability; software; program; process.

1. Introduction

Computers are becoming faster and more complex.

In addition, software is intimately related to achieving

quality of service. As a result, attempts to repair software

problems and improve functionality are made from time to

time. In terms of service, it would be extremely beneficial

to be able to make such changes to software while a pro-

gram is being executed.

One method to alter a program while it is being run

as a process is a method [1] of structuring a process redun-

dantly and then exchanging the program in process units.

In this method, the entire process must be exchanged even

if only a portion is being altered, because the exchange is

performed in process units. On the other hand, there have

been reports of a method [2] of exchanging part of a

program while a process is being executed. However, these

methods must consider the timeliness of the exchange for

the service program being exchanged and must rely on the

operating system (OS). As a result, the creation of a service

program that is aware of the timeliness of the exchange

becomes necessary. In addition, if several processes created

from the same program are running, then the program

process structure becomes complex.

The authors propose a method with two major char-

acteristics as a method to alter part of a program being run

as a process [3, 4]. The first is that the service program does

not need to be aware of the timeliness of the exchange. The

second is that program exchange is possible even when the

part of the program being exchanged calls a separate part

of the program not being exchanged.

On the other hand, programs include application

programs running as processes (AP) and OS programs. In

Refs. 3 and 4, an exchanging method for APs is described,

but nothing regarding OS programs is mentioned. In addi-

tion, the time during which the process is stopped for the

© 2001 Scripta Technica

Systems and Computers in Japan, Vol. 32, No. 8, 2001Translated from Denshi Joho Tsushin Gakkai Ronbunshi, Vol. J82-D-I, No. 8, August 1999, pp. 998�1007

53

exchange is not described. The order of exchanging time

for APs is clarified in Refs. 3 and 4, but this issue remains

unclear for OS programs. In particular, because the extent

of sharing for OS programs is high, there is a possibility

that the exchanging time will be larger.

Thus, in this paper the authors classify the charac-

teristics of programs, including both AP and OS pro-

grams, and then present a relationship for the exchanging

method. The authors then consider both AP and OS

programs, and formalize the exchanging time and the

time during which a process is stopped for an exchange,

and finally further clarify the features of the exchanging

method. In addition, they demonstrate the validity of

their formulation through comparisons with real-world

measurements.

2. Program Characteristics

A program that is being shared can be broken down

into the following two categories based on the execution

format resulting from the execution units (referred to as

threads) allocated by the processor.

(Category 1) Program parts which are executed using

several threads at the same time.

(Category 2) Program parts for which one and only

one thread is executed at a time.

In Category 1, program parts are shared among

threads, and context exchanges occur in the applicable

program parts. This holds for program parts that are

not controlled nonexclusively and for many APs. In

addition, this also holds for OS programs that enable

preempting for execution rights when being run in

kernel mode, as is represented by real-time OSs. In

Category 2, program parts are shared among threads,

but context exchanges do not occur in the applicable

program parts. This holds for OS programs which do

not allow for the preempting of execution rights when

being run in kernel mode and for program parts that

are controlled nonexclusively.

When viewed from the perspective of exchanging,

the program parts in Category 2 are the same as when the

status of the program parts [4] is not shared, although the

sharing of program parts between threads is not performed.

Here, in Ref. 4, the status of the program part can be one of

the following: not used, being run, or being called. Not used

represents a status prior to execution or after the completion

of execution. Being run represents a status in which execu-

tion is under way, and being called represents a status in

which a separate program part is being called. As a result,

the module status that can be created for the Category 2

program part is a portion of the module status that can be

created for the Category 1 program part. Thus, hereafter the

Category 1 program part will be used. In addition, the

program part will be referred to as a module, and the

program part being exchanged will be referred to as an

exchange module.

Next, AP and OS programs will be compared. An AP

has the following features.

(1) Several different APs are executed at the same

time.

(2) Each program part during execution is handled as

follows.

(a) Text segments are shared among processes started

from the same AP.

(b) Data segments have parts that are not shared with

other processes and parts that are shared with related proc-

esses.

(c) Stack segments are not shared with other proc-

esses.

(3) Preempting of execution rights during the execu-

tion of a program can occur.

In contrast, an OS program has the following fea-

tures.

(1) Two OS programs cannot be run at the same time.

(2) The program is shared by all processes.

(3) Some OSs allow for preempting of execution

rights when a program is being executed and others do not.

(4) Some parts are always being used as exchange

parts with execution rights.

In addition, compared to an OS program, an AP does

not place heavy demands on execution time. On the other

hand, an OS program does place heavy demands on execu-

tion time.

In this fashion, an AP and an OS program are sub-

stantially different. However, when viewed from the per-

spective of exchanging programs, only the extent of sharing

and the size and number of modules are different. There-

fore, using these differences as parameters, if the exchang-

ing time and the time effects on service can be clarified

when several modules are exchanged at once and modules

are shared among various threads, then the characteristics

of exchanging can be understood for both AP and OS

programs.

3. Formulation

3.1. Exchanging time

3.1.1. Formulation

In order to formalize the exchanging time, the follow-

ing assumptions must be made.

54

(Assumption 1) Exchanging is possible when the

module status is unused or being called.

(Assumption 2) The status is acquired when the pro-

gram starts.

(Assumption 3) Exchange requests can be issued for

several modules at the same time.

(Assumption 4) After an exchange request, execution

cannot be transferred to the exchange module.

(Assumption 5) Modules are shared among all

threads.

As indicated in Ref. 4, here the module status can be

classified as �not used,� �being run,� or �being called.�

�Being run� modules cannot be exchanged. Assumption 1

is an assumption that considers this point. Also, acquiring

the module status can start before an exchange request or

when a program launches. In either case, the maximum

value for the interval during which control is transferred

among modules in the program overall affects the exchang-

ing time. When starting just before an exchange request,

temporary effects on the run status when an exchange

request is received can readily occur. As a result, this effect

must be eliminated (Assumption 2). Assumption 4 depends

on the structure of the authors� proposed exchanging

method. Assumption 3 is an assumption that considers

convenience, that is, being able to make requests once and

not again and again for each module for which a program

exchange is to be performed. Assumption 5 assumes the OS

program shares modules among all threads. For an AP

program, the number of threads shared by the modules may

be considered instead of Assumption 5, but in this case, the

exchanging time has been shown to be shorter than the time

when modules are shared among all threads [4]. As a result,

Assumption 5 is used.

In addition, the following prerequisites apply.

(Prerequisite 1) All modules are called without bias.

(Prerequisite 2) Execution is performed using the

number of threads running and the same number of proces-

sors. In other words, module processing time does not rise

due to an increase in the number of threads running.

These two prerequisites make the formulation sim-

pler. A case in which Prerequisite 1 is removed from con-

sideration is explained later as an approximation of call bias

with the number of modules. A case in which Prerequisite

2 is removed from consideration is also explained later.

Modules to be exchanged are referred to as A = {A1,

A2, . . . , Ax}, and modules that are not to be exchanged are

referred to as B = {B1, B2, . . . , By). Figure 1 shows this

situation. The arrows in Fig. 1 indicate the transfer of

running modules for threads, in the form of calls to modules

and returns from modules, and may vary depending on the

program structure. In addition, the number of running

threads is n; the expected value for the processing time for

the modules to be exchanged A is a = a1 + a2 + ����� + ax (ai:

the expected value for the time at which the thread stops at

Ai); and the expected value for the processing time for the

modules not to be exchanged B is b = b1 + b2 + ����� + by (bi:

the expected value for the time at which the thread stops at

Bi).

At first, the timeout time is infinitely large, as per

Assumption 4. The expected value TA for the exchanging

time when a running thread is needed for the exchanged

module can be found as follows. If the expected value for

the number of threads when the exchanged module Ai is

running is set to nAi, then given the condition that a running

thread is needed for the module to be exchanged and

Prerequisite 1,

The expected value for the time required for nAi threads

being run in the exchanged module Ai to perform the

module transition is TAi. TA

i is the time elapsing between the

issuing of a request for an exchange of module Ai and the

time at which the exchange becomes possible, and can be

found as follows. When a thread performs the processing

for module Ai in time t, the time required for the module

transition is ai � t, based on Prerequisite 2. The probability

that nAi threads are found in the interval [t, ai] can be

expressed as ��ai � t� /ai�nAi. When this condition is satisfied,

the probability of the time from when an exchange request

Fig. 1. Connection among modules.

55

for module Ai is issued to when it can be performed for the

time ai � t for the module transition of the thread in the

interval [t, t + 't] is �nAi � 't� / �ai � t�. Therefore, the ex-

pected value for TAi is

The exchanging time is the time required for all

Ai�i 1, 2, . . . , x� to be able to be exchanged. In other

words, the maximum value for TAi�i 1, 2, . . . , x� is

equivalent to the exchanging time. Therefore, TA is

Next we will find the exchanging time TB when no

threads are present in the exchanged module when an

exchange is requested. The number of threads running the

set of modules B not to be exchanged is represented by nB.

Because of the condition that the threads running the mod-

ules not to be exchanged, nB n. Here, the processing time

relationship for the modules not to be exchanged is

b1 L b2 L . . . L by. The probability that more than time t will

be required to complete processing in all current modules

is ��b � yt� / b�n when 0 L t L b1, and �6j iy �bj � t� /b�n when

bi�1 L t L bi�i 2, 3, . . . , y�. In addition, the probability

that a process is present over the interval [t, t + 't] is

n �y � 't� / �b � yt� when 0 L t L b1, and n ��y � i � 1� �

't� /6j iy �bj � t� when bi�1 L t L bi�i 2, 3, . . . , y�. Given

that the exchanging time is t under these conditions, TB is

Here, if the processing time for the case in which the

modules not to be exchanged can be approximated using

the average value b/y is replaced with TBg , then

Finally, we will find the general exchanging time T.

The probability that TB is valid is �b / �a � b��n and the

probability that TA is valid is 1 � �b / �a � b��n. Therefore,

the general exchanging time T based on Assumptions 1

through 4 and Prerequisites 1 and 2 is

3.1.2. Evaluation and discussion

Based on T obtained in the previous section, the

exchanging time will be evaluated from three perspectives:

the number of threads, the number of modules, and the

module processing time.

The relationship between the number of threads and

the exchanging time is shown in Fig. 2 for the following

conditions.

(Condition 1) The number of threads n = variable.

(Condition 2) The number of modules x + y = 4000.

(Condition 3) The number of modules to be ex-

changed x = 4, 40, 400.

(Condition 4) The module processing time (average)

ai, bj = 10 Ps.

A BSD-UNIX OS kernel with a running program size

over 1 MB was used as reference for the conditions above.

The majority of BSD-UNIX OS kernels are written in the

C programming language, and are composed of around

4000 functions. As a result, the number of modules was set

to 4000. Because a single function is not particularly large,

a somewhat large number of execution commands, 1000,

was considered, and executed under a 100 MIPS processor,

the module processing time was set to 10 Ps. The number

of threads was considered to be the number of threads that

Fig. 2. Number of threads versus exchanging time.

56

can run simultaneously on a single computer, and the maxi-

mum for this number was set to 500. Here the OS kernel

was used for reference, and the number of modules and the

number of threads were set very high. For an AP program,

these values would usually be smaller, and the exchanging

time would also be briefer. In addition, because of rapid

increases in processor performance accompanied by pro-

grams becoming more modular in recent years, the module

processing time would often be less than 10 Ps. Given the

above, the evaluation below can be considered to be close

to a worst case.

Figure 2 shows the relationship for x = 4, x = 40, and

x = 400, that is, for the three cases in which the portion of

the overall program to be exchanged is 0.1%, 1%, or 10%.

Based on Fig. 2, when the number of threads rises, the

exchanging time drops briefly, and then rises. The exchang-

ing time when there are 100 threads is shorter than for 3 or

4. When the number of threads is low, the probability that

a thread is in the module to be exchanged during an ex-

change request is low. As a result, the exchanging time

affects TB significantly. TB is a monotonically decreasing

function with respect to the number of threads, and so the

exchanging time falls as the number of threads rises. When

the number of threads is large, the exchanging time affects

TA significantly. TA is a monotonically increasing function

with respect to the number of threads, and so the exchang-

ing time rises as the number of threads rises. The number

of modules to be exchanged only affects the ratio of TA and

TB with respect to T, and does not affect the values of TA

and TB. As a result, differences in x have little effect on the

exchanging time.

Figure 3 shows the relationship between the exchang-

ing time and the module processing time under the condi-

tions noted below. Here, the scale of the program overall is

considered using the total module processing time. Thus,

because the scale of the program overall is the product of

the number of modules and the module processing time, the

scale of the program overall in Fig. 2 is 40,000 Ps. The scale

of the program overall is the same as in Fig. 2, so Conditions

2 and 4 apply.

(Condition 1) Number of threads n = 50, 250, 500.

(Condition 2) Number of modules x + y = 40,000/t.

(Condition 3) Number of modules to be exchanged

x = 1.

(Condition 4) Module processing time (average)

ai, bj t Ps.

Figure 3 shows that the exchanging time rises in a

linear fashion with respect to the module processing

time. This means that if TAi and nA

i are put in place of

TA, then

A rise in ai includes a rise in a. In particular, under the

condition that x = 1, ai a. Therefore, TA can be considered

almost proportional to the processing time for modules to

be exchanged, and when the number of threads rises, this

trend approaches 1. Although TB is proportional to the

processing time for modules not to be exchanged, the trend

is weak compared to that of TA. There is a tendency for the

ratio of TA to T to rise when the number of threads rises, and

so a rise in the module processing time significantly affects

the exchanging time.

Moreover, by comparing the exchanging time when

x = 40 and the number of threads is 500 in Fig. 2, that is,

roughly 1 Ps, and the exchanging time when n = 500 and

the module processing time is 400 in Fig. 3, that is, roughly

325 Ps, the difference in the exchanging time due to module

separation can be determined. The exchanging time when

a program requiring 400 Ps for processing is defined as one

module is roughly 300 times greater than the total exchang-

ing time when such a program is broken down into 40

modules.

Next we will consider Prerequisite 1, that all modules

are called without bias. The call bias is approximated by

using the number of modules. A case in which the percent-

age of the number of modules to be exchanged is high with

respect to the total number of modules can be considered a

case in which there is a bias in the calls to the modules to

be exchanged. Figure 4 shows the relationship between the

number of modules and the exchanging time under the

following conditions.Fig. 3. Module processing time versus exchanging time.

57

(Condition 1) Number of threads n = 50, 250, 500.

(Condition 2) Number of modules x + y = variable.

(Condition 3) Number of modules to be exchanged

x = 4.

(Condition 4) Module processing time (average)

ai, bi = 10 Ps.

In Fig. 4, as the number of modules falls, in other words, as

the percentage of the number of modules to be exchanged

with respect to the total number of modules rises, the

exchanging time increases as the number of threads rises.

The maximum duration of the exchanging time is 10 Ps, the

module processing time (average).

Now we will consider Prerequisite 2, the number of

running threads executed by the same number of proces-

sors. For the sake of simplicity, we will consider the ex-

changing time for a single processor to be a multiple of the

number of processors for multiple processors. Thus, the

conditions are the same as for Fig. 2. Figure 5 shows the

exchanging time for the time for which the number of

threads is doubled over the exchanging time in Fig. 2. In

Fig. 5, if the number of threads is 500, when 1% of the

program is altered (when x = 40), the exchanging time for

a single processor is roughly 550 Ps.

3.2. Effects on service time

3.2.1. Formulation

In this section the thread stoppage time due to ex-

changing control is formulated, and its effects on service

are described. In this formulation, Prerequisite 3 is added

to the same assumptions and prerequisites used for the

exchanging time.

(Prerequisite 3) There is no major difference in the

processing time in each module.

As was described previously, the module to be ex-

changed is defined as A = {A1, A2, . . . , Ax}, the other

modules that will not be exchanged as B = {B1, B2, . . . , By},

the number of running threads as n, the expected value for

the processing time for A as a = a1 + a2 + ����� + ax (ai: the

expected value for the time at which the thread stops at Ai),

and the expected value for the processing time for B as a =

b1 + b2 + �� �� � + by (bi: the expected value for the time at

which the thread stops at Bi).

First, the expected value SA�n 1� for the thread stopped

time is found for when the number of threads is 1 and a

single thread is in the module to be exchanged. In this

instance, the single thread is what determines the exchang-

ing opportunity. As a result, the thread will not be stopped.

Therefore,

Next, the expected value SA�nM2� is found for the stoppage

time for one thread for when the number of threads is two

or more and the threads are in the module to be exchanged.

In order to find SA�nM2�, the sum n �SA�nM2� for the stopped

time for all threads must be found first. The residual time

up to the time when the thread is transferred from its current

module to another module will be t. When the number of

threads being run in the module to be exchanged is nA, if

the exchanging time is TA�nA�, then

Fig. 4. Number of modules versus exchanging time.Fig. 5. Number of threads versus exchanging time.

(case of single processor)

58

Given Assumption 4, the thread stoppage time is the time

from when the transfer to the module to be exchanged starts

to when the exchange is finished. In addition, given Prereq-

uisite 3, the module transfer over the interval from exchange

request to exchange completion is under one time for a

thread. Therefore, the thread stopped time can be repre-

sented as TA�nA� � t. Based on Prerequisite 1, the prob-

ability that the transfer destination for the module being

transferred is the module being exchanged is x/(x + y). The

expected value for the number of threads in the interval

[t, t � 't] for the module Ai to be exchanged is

nA �ai / a� � �'t /ai� nA �'t / a�. Therefore, when the num-

ber of threads being run in the module to be exchanged is

nA (note that nA M 0�, if the expected value for the total sum

of the thread stopped times in the module to be exchanged

is set to SAA�nA�,

The probability that nA threads are in the module to be

exchanged is n! /nA!�n � nA�! �a /a � b�nA �b /a � b�n�nA.

Given this, if the expected value for the sum of the thread

stopped times in the module to be exchanged is set to SAA,

then

In the same fashion, if the expected value for the total sum

of the thread stopped time in the modules not being ex-

changed is set to SAB, then

Given the above, n � SA�nM2� is

Therefore, the expected value SA�nM2� for the stoppage time

for one thread when there are two or more threads and the

running threads are in the module to be exchanged is

Next we will find the expected value SB for the thread

stoppage time when the thread is not in the module to be

exchanged. In this instance, the module is executed with the

thread which first arrives at the module boundary, and as a

result, there is no stopped thread. Thus,

Finally, let us find the general thread stopped time S.

The probability that a thread is not present in the module to

be exchanged is �b / �a � b��n, and the probability that a

thread is present in the module to be exchanged is

1 � �b / �a � b��n. Therefore, based on Assumptions 1

through 4 and Prerequisites 1 and 2, the general thread

stoppage time S is

3.2.2. Evaluation and discussion

Based on S obtained in the previous section, the

thread stopped time will be evaluated from three perspec-

tives: the number of threads, the number of modules, and

the module processing time.

Figure 6 shows the relationship between the number

of threads and the thread stoppage time under the same

conditions as in Fig. 2. Figure 6 shows that a rise in the

number of threads increases the thread stoppage time. Be-

cause a rise in the number of threads increases the coeffi-

cient SA�nM2�, the thread stoppage time will tend to increase

as a result of the rise in the number of threads. In addition,

the percentage of parts being exchanged with respect to the

program overall and the probability that a thread being

transferred in a module will be stopped are the same: x/(x

+ y). As a result, a rise in the percentage of the parts being

exchanged with respect to the program overall will increase

the probability that a thread being transferred in a module

will be stopped. As a result, the rise in thread stopped time

with respect to the number of threads is sharp.

However, even when 10% of the program overall is

exchanged, the thread stoppage time is small at only 0.1%

of the module processing time.

Figure 7 shows the relationship between the thread

stoppage time and the module processing time under the

59

same conditions as in Fig. 3. Figure 7 shows that the thread

stoppage time rises linearly with respect to the module

processing time. A rise in the module processing time

increases the exchanging time TA, and as a result leads to

an increase in the thread stoppage time. When the number

of threads is large, the ratio of SA�nM2� to S rises, and so the

impact on the thread stoppage time of the module process-

ing time is large.

A comparison of the thread stoppage time for x = 40

and 50 threads, as in Fig. 6, to the thread stoppage time for

a module processing time of 400 and n = 500, as in Fig. 7,

reveals that the former is lower. This demonstrates that if

the ratio of the part being exchanged to the program overall

is the same, breaking up the modules to create a large

number lowers the thread stoppage time, as is the case with

the exchanging time. The thread stoppage time when the

part being exchanged is one module is 1600 times the thread

stoppage time when the part being exchanged is broken up

into 40 modules.

Next we will consider Prerequisite 1, that all modules

are called without bias. As is the case for the exchanging

time, the call bias is approximated by the number of mod-

ules. Figure 8 shows the relationship between the thread

stoppage time and the number of modules. In Fig. 8, as the

number of modules decreases, in other words, as the ratio

of the number of modules being exchanged to the total

number of modules increases, the thread stoppage time

increases as the number of modules grows larger. This is

due to an increase in the exchanging time and a rise in the

transition probability for the module being exchanged in

the module transfer in the thread. The maximum length of

the thread stoppage time when the time-out time is infi-

nitely large is 10 Ps, the module processing time (average).

Now we will consider Prerequisite 2, execution using

a number of processors equal to the number of threads being

run. The idea that the exchanging time for a single processor

could be considered to be a multiple of the number of

processors when several processors were used was de-

scribed in the evaluation of the exchanging time. Therefore,

Fig. 9 shows the stoppage time when the exchanging time

and the remaining time until module transfer are considered

by using a multiple of the number of processors. The

conditions are the same as in Fig. 6. In Fig. 9, when the

number of threads is 500, if 1% of the program is altered

Fig. 6. Number of threads versus stopped time.

Fig. 7. Module processing time versus stopped time. Fig. 8. Number of modules versus stopped time.

60

(if x = 40), then the thread stoppage time for a single

processor is roughly 0.4 Ps.

3.3. Comparison with measurements

An evaluation was performed using an AP process for

which part of a program was executed using several threads

at the same time (Category 1). In what follows, the threads

function as processes.

First the validity of the formulation for the exchang-

ing time will be verified. Case A from the measurements

(Ref. 4 in Fig. 10) from Ref. 4 is used for the comparison.

Figure 10 shows the results of the comparison. In Fig. 10 it

is clear that the formulated exchanging time and the meas-

ured values are a close match, regardless of the number of

threads shared in a program.

Next the validity of the formulation for the thread

stoppage time will be verified from the perspective of

effects on service. The measurement conditions are the

same as in Fig. 10. Measurements were performed 25 times,

with the average values taken as the results of the measure-

ments. Figure 11 shows a comparison of the results. Based

on Fig. 11 it can be said that the formulated stoppage time

and the measured values follow the same trend. The ran-

domness in the measurements is a result of iteration from

the stoppage point, in other words the schedule used is

dependent on the execution state at that time during re-

scheduling. In addition, because the OS overhead for con-

trolling the threads rises as the number of threads increases,

the stoppage time is affected. As a result, when the number

of threads is increased, the measured stoppage time exceeds

the formulated stoppage time, and the difference between

the two rises.

4. Conclusions

The authors have described how a method of ex-

changing part of a program during its execution is related

to program characteristics. They have formulated the ex-

changing time and the thread stoppage time during which

the thread is stopped so it can be exchanged. Under appli-

cation programs that share execution units (threads) allo-

cated in a processor, or operating system programs that can

be preempted, parts of several programs must be exchanged

at the same time. These program parts are shared among

Fig. 9. Number of threads versus stopped time (case of

single processor).

Fig. 10. Exchanging time (formulation and

measurement).

Fig. 11. Stopped time (formulation and measurement).

61

many threads. The formulation shows that the exchanging

time rises along with the processing time for the program

part to be exchanged, and that the impact on the number of

threads which a program shares is minimal. In addition, the

thread stoppage time during which a thread is stopped so

that it can be exchanged is shown to rise along with the

number of shared threads and the processing time for the

program parts to be exchanged. Both of these are consistent

with intuitive interpretations. The authors have demon-

strated the validity of their formulation through compari-

sons with real measurements. According to the formulation,

when the number of threads being run at the same time is

500, the exchanging time when 1% of a program is being

altered is roughly 550 Ps. In addition, the thread stoppage

time for exchanging under these conditions is roughly 0.4

Ps.

A remaining topic is the evaluation of a method to

swap a part of a program being executed with a different

program. The validity of this method must be clarified

through a comparison with the exchanging method.

Acknowledgment. The authors would like to ex-

press their gratitude to Mr. Raita Nakajima of the Graduate

School of Information Science and Electrical Engineering

at Kyushu University for his cooperation in the preparation

of this paper.

REFERENCES

1. Muramatsu H, Date M, Yoshida H, Kitaoka M, Kuro-

bane N. Operating system SXO for continuous op-

eration. IFIP 92, Vol. 1, p 615�621.

2. Snead B, Ho F, Engram B. Operating system features

real time and fault tolerance. Computer Design, p

177�185, Aug. 1984.

3. Taniguchi H, Ito K, Ushijima K. A parts exchanging

method for programs during process execution. Trans

IEICE 1995;J78-D-I:492�499.

4. Taniguchi H, Goto M. A parts exchanging method for

programs shared in processes being run. Trans IEICE

1997;J80-D-I:495�504.

AUTHORS (from left to right)

Hideo Taniguchi (member) received his B.E., M.E., and Ph.D. degrees in computer science from Kyushu University in

1978, 1980, and 1991. He joined NTT Electrical Communication Laboratories in 1980, and moved to the Research and

Development Headquarters of NTT Data Communications Systems Corp. in 1988. After becoming an associate professor of

computer science at Kyushu University in 1993, he has been an associate professor in the Graduate School of Information

Science and Electrical Engineering since 1996. His research interests include operating system, real-time processing, and

distributed processing. He is the author of Operating Systems (Shokodo). He is a member of the Information Processing Society

of Japan, IEICE, and ACM.

Masataka Goto received his B.E. and M.E. degrees from Kyushu University in 1995 and 1997. He then joined the

Communication and Information Systems Research Labs., Research and Development Center, Toshiba. His research interests

include operating systems and secure communication over the Internet. He is a member of the Information Processing Society

of Japan.

62