Evolutionary Computation for Scheduling Controls
in Concurrent Object-Oriented Systems
Tzilla Elrad
Concurrent Programming Group
Computer Science
Illinois Institute of Technology
Chicago, IL 60616
cselrad@minna.cns.iit.edu
(312) 567-5142
|
Jinlong Lin
Concurrent Programming Group
Computer Science
Illinois Institute of Technology
Chicago, IL 60616
linjinl@minna.cns.iit.edu
(312) 949-1415
|
Douglas J. Cork
Computer Visualization of Genomes
Biological, Chemical & Physical Sciences
Illinois Institute of Technology
Chicago, IL 60616
cork@charlie.cns.iit.edu
(312) 567-3492
|
Abstract
We present our concept of evolution scheduling, which will provide a better
scheduling mechanism for competing processes in the ready queue and
the blocked queue. Evolution scheduling is acceptable for real-time systems
and useful for achieving fair and effective scheduling. Queue dispatching and
process dispatching of the evolution scheduler can be substituted for the
round robin, priority, and FIFO scheduling, without warning the application
programmers to change their expectation of the scheduling controls.
On the other hand, for those who pursue evolutionary computation, this is good news.
It allows them to carry out natural competition in an easy way consistent with their
operating system and programming language. Each evolving process, one with
the ability to improve its adaptation to the environment, reflects on the
CPU usage rate and I/O throughput load with its fitness function, and the
evolution scheduler elaborates the optimization winner for the next quantum.
There are many benefits for both scheduler designers and evolutionary programmers.
Keywords:
Evolving Processes, Evolution Scheduling, Genetic Algorithms, Evolutionary Programming, and Comprehensive Concurrent Controls
1 Introduction
We are interested in adding reactive/adaptive and reflective facilities
to concurrent object-oriented programming languages. It goes without saying
that this is an effective method to directly apply artificial intelligence to
concurrent systems. However, there is always another approach. We recommend
an evolutionary approach to the same goal that provides a new framework with
intelligent stochastic optimization. This approach indirectly but eventually
achieves reactive/adaptive and reflective intelligence. Nevertheless, this kind
of intelligence, using an evolutionary natural selection approach, may be more
efficient than the artificial intelligence approach.
Evolutionary computation makes every effort to make good use of parallel
and distributed computers to improve speed and efficiency. Nowadays the
concurrent programming languages have been implemented on many platforms
including both uni-processor and multiprocessor architectures. So the
problem of speed-up is no longer how to distribute the system load to parallel
machines, but how to give parallel machines the ability of evolutionary and
concurrent computation. In this paper we will show that employing evolutionary
concurrent object-oriented systems will benefit both concurrent programming
users and evolutionary computation users.
There are two major comprehensive concurrency controls on
existing concurrent
programming languages. One is named availability control, and the other is
race control. Sometimes, we call them synchronization control and scheduling
control respectively. As we can see all the selection mechanisms are usually
implemented implicitly by using FIFO or round robin semantics. We assert
that a good scheduling control should be naturally fair and also prevent
deadlock, starvation and bottleneck. The explanation of the deficiency in
concurrent programming languages is the lack of stochastic optimization
algorithms built-in inside operating systems and primitive functions. However,
this situation can be improved by alloying evolutionary computation with
the concurrent object-oriented systems. To achieve this purpose we employ
a patch of Linux and a generic GNU C++ compiler to recognize and realize
the evolutionary concurrent scheduling control syntax and semantics.
At the same time we introduce evolutionary classes that satisfy all the
necessities of decision makers (process servers and process schedulers) and
make the implementation of evolving processes and evolution scheduling easier.
2 Evolving Processes and Evolution Scheduling
Any process should reside in either the ready state or blocked state
if it is not running. In the ready state there are many ready queues if
the scheduler is implemented to carry out two-dimensional scheduling.
As in Figure 2.1 we can see that there are two ready queues, and the
ready-queue scheduler is in charge of scheduling the queue dispatching
and process dispatching. Also, in the blocked state there are many blocked queues.
Figure 2.1: Ready Queues and Blocked Queues
Evolution scheduling is proposed to solve the problem of optimization
of ready-queue scheduling, blocked-queue scheduling, priority-control-queue
scheduling, and client-server-queue scheduling.
Figure 2.2: Flow Chart for Evolution Scheduling
Figure 2.2 shows a flow chart for evolution scheduling.
Evolution scheduling starts from the manipulation of fitness of queues
and ends with the optimal process. Note the following in Figure 2.2.
[1] Resetting the guarantee value of the queues,
[2] resetting the guarantee value of the processes,
[3] evolutionary programming for queue dispatching, and
[4] genetic algorithms for process dispatching.
2.1 Evolving Processes
If a process is confronting the competition of evolution scheduling,
we will call the process an evolving process. Evolving processes
can adapt to the environment by changing their fitness functions.
This kind of reaction can make a process always suitable for the
fluctuation of CPU usage rate and I/O throughput load.
2.2 Evolution Scheduling
Evolution scheduling is divided into two parts, queue selection
and process selection. In the first phase of queue selection we
employ evolutionary programming to choose an optimum queue,
which will be used later to get the winner process. In the second phase
of process selection we apply genetic algorithms for the selection
of the process to run at the next quantum of CPU time.
Figure 2.3: Two Phases of Evolution Scheduling
(We define a class as a collection of queues.)
2.3 Fitness Functions and Objective Functions
We define the objective function to be a measure of relative
fitness in the problem domain. Each process is born with an
objective function that will be transferred to be fitness value,
and the fitness value is the base to be used to decide which
process has the right to be granted the next quantum of CPU.
In the current stage we just simply set the fitness function to
be the objective function.
.......................................... [2.1]
In our evolution scheduling we define the fitness value
to be an integer ranging from 0 to 255. The higher the
fitness value of a process is, the stronger the process is
in competition with others. The fitness function can include system
variables, such as CPU usage rate, I/O throughput load, current time,
or even a run-time random number generated by any algorithm.
Table 2.1: System Variables Available
| System Variables | Description |
| es_cpu | total cpu usage |
| es_cpu_sys | cpu used by system processes |
| es_cpu_idle | cpu unused |
| es_load | system load |
| es_proc | number of processes |
| es_context | number of context switches |
| es_swap | amount of swapping |
| es_page | amount of paging |
| es_disk | amount of disk accesses |
| es_intr | number of interrupts |
| es_mem_free | mb amount of free memory |
| es_mem_used | mb amount of used memory |
2.4 Guarantee Values and Chromosome Values
A chromosome is a representation in which there is a list
of elements called genes, and an allele is one member of a
pair or series of genes that occupy a specific position on a
specific chromosome. See Figure 2.4.
Figure 2.4: An 8-bit Chromosome
The chromosome value is the binary expression of the fitness value,
and the fitness value is the decimal expression of the chromosome value.
.......................................... [2.2]
Evolution scheduling uses chromosomes to manipulate the recombination
and mutation, however, it uses the fitness values to decide the optimal process.
Also, we set the initial guarantee value to be the initial
fitness value. The guarantee value is used to prevent starvation
from happening. When a winner process or a winner queue is selected,
the process guarantee or the queue guarantee will be reduced by one.
This is a convenient way to implement and apply the evolution scheduling.
During a cycle of competition each process will be assured at least
one chance to get the CPU.
..................................................... [2.3]
2.5 Process Dispatching and Queue Dispatching
Process dispatching can be implemented by many methods,
such as FIFO, round robin, priority, shortest job first,
and guaranteed scheduling. However, we introduce a new mechanism,
the genetic algorithm, to be used in the process dispatching.
Genetic algorithms are the best way to select a winner for the
same-purpose processes to compete with one another. Following
is the pseudo code of our genetic algorithms for process dispatching.

Program 2.1: Pseudo Code for Process Dispatching
Queue dispatching is as important as process dispatching.
Especially when we implement the evolution scheduling for
the ready-queue process scheduling. Actually before we can
ick the right process, we have to pick the right queue first.
This is why we have to use the evolutionary programming for
the queue dispatching.

Program 2.2: Pseudo Code for Queue Dispatching
2.6 Genetic Algorithms and Evolutionary Programming
Genetic algorithms are suitable for the competition of the
same kind of population. So we recommend its use in our
process-dispatching scheduling. However, the genetic algorithm
needs a complicated calculation to determine the final winner.
The major manipulations for the genetic algorithm are
[1] the recombination operation, [2] the inversion operation,
[3] the mutation operation, and [4] the reinsertion operation.
In practice, we have to simplify all the operations in order
to meet the real-time requirement.
Evolutionary programming typically uses stochastic selection
via a tournament. Evolutionary programming is an abstraction
of evolution at the level of reproductive populations and thus
no recombination mechanisms are typically used because recombination
does not occur between species. Evolutionary programming is the best
method for the competition of different kind of populations compared
to other evolutionary algorithms. We select evolutionary programming
for our queue-dispatching scheduling, and simplify the procedures to
obtain the optimization.
Table 2.2: Genetic Algorithms vs. Evolutionary Programming
| Evolution Scheduling | Genetic Algorithms | Evolutionary Programming |
| Dispatching | Process Dispatching | Queue Dispatching |
| Scheduling | Intra-Queue Scheduling | Inter-Queue Scheduling |
| Recombination | Yes | No |
| Mutation | Yes | Yes |
| Selection Method | Highest Fitness | Fitness + Stochastic |
2.7 OS Scheduling and PL Scheduling
An operating system has two kinds of queues, ready queues and
blocked queues, and a programming language has two kinds of queues
too, pc queues and cs queues. The queue in which processes wait
for the priority scheduler to determine which one should go first
is called a pc queue, priority-control queue. This queue is provided
by the programming language itself. However, the queue in which
client processes wait for the forerunner and preference server
schedulers is called a cs queue. This queue is provided by the server
process, so we name it the client-server queue.
Table 2.3: Comparisons of Scheduling Queues
| Scheduling Queues | Ready Queues | Blocked Queues | PC Queues | CS Queues |
| Scheduling Levels | Operating System | Operating System | Programming Language | Programming Language |
| Scheduling Units | Operating System Scheduler | System Scheduling Routines | Programming Language Scheduler | Server Process |
| Scheduler Responsibility | Active | Passive | Active | Passive |
| Resource Scheduled | CPU | I/O Device | Blocked Queue | Service |
| General Scheduling Controls | RoundRobin, Priority, etc. | FIFO | Priority Controls | Forerunner & Preference Controls |
| Scheduler Implementation | Required | Required | Optional | Required |
| Evolution Scheduling Applicable | Yes | Yes | Yes | Yes |
When a client process in the cs queue is allowed to get a service
from a server process in the running state, the client process will
be moved from the cs queue to the pc queue. When the pc-queue scheduler
assigns the client process to go for the next turn, the client process
will be moved from the pc queue to the blocked queue. Since the blocked
queue is in the operating system layer, and when the shared I/O resource
is available, the client process will be moved from the blocked queue
to the ready queue. When the ready-queue scheduler chooses the client
process to use the CPU and get the service result, it will enter into
the running state. When the rendezvous is finished, the client process
may go back to the cs queue to wait for another service by way of the
blocked queue, and the pc queue. See Figure 2.5.
Figure 2.5: OS Scheduling and PL Scheduling
2.8 Real-Time Scheduling and High-Performance Scheduling
A real-time scheduler is one that is required to perform scheduling
actions within time constraints. The system that the scheduler controls
will not function correctly unless these time constraints are met.
So real time is the highest goal of each scheduler. However,
the real-time requirement will somewhat reduce performance in return.
Also, the real-time constraints will largely restrict the scheduler
to be designed too complicated to commit to the limitation of response time.
Figure 2.6: Real-Time Scheduling and High-Performance Scheduling
Figure 2.6 shows that the limitation of real time for the ready
queue is lower than for the blocked queue. For the blocked queue
it is much lower than for the application. Nevertheless, the
evolution scheduling is modified in a simple way to get quick
optimization and meet the limitation of the real time even for the ready queue.
2.9 Comparisons of Process Scheduling
Evolution scheduling can be implemented to replace any existing
scheduling control. Users can apply an appropriate fitness function
to simulate any scheduling control, so the evolution scheduling
queuing policy is always controlled by users.
2.9.1 Evolution Scheduling vs. Round Robin Scheduling
When users set the queue number to be one and each process
fitness value to be one, evolution scheduling will be very
similar to round robin scheduling. In the simulation we emphasize
on the equal opportunity to use the CPU power, not on the order
to run programs.
Figure 2.7: Evolution Scheduling vs. Round Robin Scheduling
(The number beside an arrow is the fitness value.)
2.9.2 Evolution Scheduling vs. Priority Scheduling
When users set the queue fitness value relative to the
process priority level, and each process can only go into its
specified priority queue, evolution scheduling will be very
similar to priority scheduling.
Figure 2.8: Evolution Scheduling vs. Priority Scheduling
2.10 Flexible Mechanisms and Rich Policies
Genetic algorithms and evolution programming are a good pair for
process dispatching and queue dispatching. Table 2.4 shows that
evolution scheduling has a more flexible mechanism than traditional
scheduling. All the merits make evolution scheduling a potential
dominator in the field of concurrent scheduling controls.
Table 2.4: Flexible Mechanisms of Evolution Scheduling
| Mechanisms | Evolution Scheduling | Traditional Scheduling |
| Features of Mechanisms | Flexible | Fixed |
| Stackable Building Blocks | No | Yes |
| Scheduling Mechanisms | Evolution Scheduling | FIFO, Priority Scheduling |
| When to Determine | at Run Time | at Compilation Time |
Meanwhile, evolution scheduling is the only one allowing
mechanisms and policies to be implemented separately.
Evolution schedulers even leave policies open to users, and
users can employ the policies, fitness functions, to affect
the behaviors of mechanisms in order to simulate other schedulers.
Table 2.5: Rich Policies of Evolution Scheduling
| Policies | Evolution Scheduling | Traditional Scheduling |
| Number of Selections | Rich (Many) | Limited (Two) |
| Where to Declare (Generally) | in Processes | Compiling with Qualifiers |
2.11 Theorems of Evolution Scheduling
As we can see in the previous sections, the traditional
schedulers, such as [1] the round robin scheduler,
[2] the priority scheduler, [3] the multiple queue scheduler,
[4] the shortest job first scheduler, [5] the guaranteed scheduler,
[6] the two-level scheduler, and [7] the FIFO scheduler, can be
simulated and replaced by the evolution scheduler with a proper policy.
We’d like to introduce a theorem of evolution scheduling to cover
the flexible mechanisms and the rich policies.
Theorem 2.1: Flexible Mechanisms and Rich Policies
|
When a traditional scheduler is used, an evolution scheduler
with an appropriate policy can maintain scheduling expectations.
|
3 Implementation
We have built process objects and scheduler objects to
support ready-queue scheduling control, blocked-queue
scheduling control, priority-control-queue scheduling control,
and client-server-queue scheduling control.
3.1 Ready-Queue Scheduling Controls
Ready-queue scheduling control is regarded as the
traditional scheduling problem, which has been discussed
in many textbooks. Although many solutions have been proposed,
there are only two of them, round robin scheduling and priority
scheduling, easy to implement in reality. Our evolution
scheduling is an intelligent one, which dynamically gives the next
quantum to the most-needed process. All users have to do is to set
the fitness function for each process. The fitness function includes
all the information for the evolution scheduler to decide which
process deserves how many quanta of CPU under what situation.
All the processes compete with one another for the CPU. It is a natural way,
and it is easy to implement and suitable for real-time systems.
Table 3.1: Scheduling Controls for Ready Queues
| Ready-Queue Scheduling | Queue Dispatching | Process Dispatching |
| Round Robin Scheduling | N/A | Round Robin (FIFO) |
| Priority Scheduling | Priority | FIFO |
| Multiple Queue Scheduling | Priority | FIFO |
| Shortest Job First Scheduling | N/A | Shortest Job First |
| Guaranteed Scheduling | N/A | Guaranteed CPU Time |
| Two-Level Scheduling | Priority | FIFO |
| Evolution Scheduling | Evolutionary Programming | Genetic Algorithms |
3.2 Blocked-Queue Scheduling Controls
Process-dispatching mechanisms use FIFO algorithms as we can see
in most commercial systems. In the blocked-queue evolution scheduling
we also adopt the evolutionary programming for queue dispatching and
genetic algorithms for process dispatching. Evolution scheduling will
make operating system designers pay more attentions to the importance
of blocked-queue scheduling controls.
Table 3.2: Scheduling Controls for Blocked Queues
| Blocked-Queue Scheduling | Queue Dispatching | Process Dispatching |
| FIFO | N/A | First In First Out |
| Evolution Scheduling | Evolutionary Programming | Genetic Algorithms |
3.3 PC-Queue and CS-Queue Scheduling Controls
Evolution scheduling can be used in cs-queue scheduling controls,
including forerunner control and preference control, and pc-queue
scheduling controls, including priority control. It is interesting
that the process-dispatching mechanisms used for programming language
scheduling controls are FIFO too. This is because the pc queue and
the cs queue are two kinds of blocked queues, and however, they are
applied in programming languages rather than operating systems.
We used to employ FIFO algorithms for the blocked-queue process dispatching.
Table 3.3: Scheduling Controls for PC Queues and CS Queues
| Programming Language Scheduling | Queue Dispatching | Process Dispatching |
| Forerunner Control | N/A | FIFO |
| Preference Control | Preference (Priority) | FIFO |
| Priority Control | Priority | FIFO |
| Evolution Scheduling | Evolutionary Programming | Genetic Algorithms |
3.4 Major Primitives for Process and Scheduler Classes
For evolving processes and evolution scheduling we have to
include two classes in system libraries, [1] process classes,
and [2] scheduler classes. Process classes will deal with the
creation of processes, the change of the process property, and the
closure of processes. Scheduler classes will handle the matters of
queue dispatching and process dispatching.
3.4.1 Process Classes
It is very important to provide users with a convenient way to
manage evolving processes. The simpler the object method is,
the better the primitive is. There are three preliminary primitives
for a process to grow from birth to death.
Figure 3.1: Process Class Primitives
3.4.2 Scheduler Classes
When a new process requests a ready queue, which is not
yet opened, the operating system will create for it by means of
ready-queue primitives. Also, operating systems manipulate
computational object behaviors of ready queues.
Figure 3.2: Scheduler Class Ready-Queue Primitives
Users can use the blocked-queue primitives to create a new
blocked queue, to change the fitness function, and close
the blocked queue, if authorized.
Figure 3.3: Scheduler Class Blocked-Queue Primitives
3.5 Syntax and Semantics
In this section we will deal with some related system calls
and language functions in the run time library and software
development kits. FORK and NICE system calls affect the process
priority as we can see in the Unix system. On the other hand,
WAIT/SIGNAL creates a new blocked queue for other processes to
wait for a resource to be released. For programming languages
the monitor, select/accept, availability controls and race controls
are used to control process scheduling. No matter whether they are
named synchronization controls or scheduling controls, and it
will provide one-dimensional or two-dimensional waiting queues
for processes to stay in for the next resource available.
It is time for us to give each system call or language function a
new syntax and semantics in order to implement the evolving processes
and evolution scheduler. Scheduling controls used in the programming
language will be given a new definition and usage too.
Figure 3.4: System Calls and Language Functions
In Figure 3.4 we can see that there are many functions in which
we can implement the evolution scheduling. In the blocked-queue
programming language we have to modify the forerunner control,
preference control, priority control, availability control and monitor
language functions to let their scheduling controls have abilities to
handle evolutionary algorithms. In the ready-queue operating system
we have to let the FORK and NICE system calls have the ability of
evolution scheduling, and in the blocked-queue operating system
we will enable evolution scheduling for WAIT and SIGNAL system calls.
3.5.1 Ready-Queue Evolution Scheduling
We will take care of each system call that will potentially create
a process and assign all the information for a new-born process.
In our implementation we will use our primitives discussed in the
previous section to initiate the appropriate fitness value for
evolving queues and evolving processes. For this part we have to
rewrite the system, so it will take the most time to implement the
evolution scheduling.
3.5.1.1 Fork
We define FORK as a system call that spawns or clones a new process.
When a new-born child process is created, the operating system will
assign it [1] a default ready-queue class id, [2] a default
ready-queue queue id, [3] a default ready-queue queue fitness function,
[4] a default ready-queue process fitness function, [5] a default
blocked-queue class id, [6] a default blocked-queue queue id,
[7] a default blocked-queue queue fitness function, and
[8] a default blocked-queue process fitness function, if users do not
specify proper parameters.
fork([char *es]) ....................................................... [3.1]
where es structure is
char rq_class_id[10]
char rq_queue_id[10]
char rq_queue_fitness[80]
char rq_process_fitness[80]
char bq_class_id[10]
char bq_queue_id[10]
char bq_queue_fitness[80]
char bq_process_fitness[80]
3.5.1.2 Nice
We define NICE as a system call that can change the process attributes,
such as the fitness function. Evolution scheduling of the improved
NICE can be used to change the current process’s evolution data.
nice(char pid[, char * es]) ............................................ [3.2]
where es structure is
char rq_class_id[10]
char rq_queue_id[10]
char rq_queue_fitness[80]
char rq_process_fitness[80]
char bq_class_id[10]
char bq_queue_id[10]
char bq_queue_fitness[80]
char bq_process_fitness[80]
3.5.2 Blocked-Queue Evolution Scheduling
The blocked-queue scheduler schedules any sharable resources
except the CPU, which is scheduled by the ready-queue scheduler.
The FIFO queuing policy used in blocked-queue scheduling controls
is one-dimensional scheduling, and the evolution scheduling queuing
policy is two-dimensional scheduling.
3.5.2.1 Wait and Signal
The WAIT and SIGNAL system calls are mostly used for synchronization
controls. However, we employ them for scheduling controls in evolving
processes and evolution scheduling. Users use WAIT so that the
operating system knows the queue in which this calling process is
going to wait for shared resources. This is required in the event
that the process is blocked by the operating system. The operating
system is informed by SIGNAL of the queue (in which this calling process
is going to wake up one waiting process). The scheduler of the specified
queue will determine the winning process using evolution scheduling.
wait([char* es]) ....................................................... [3.3]
where es structure is
char bq_class_id[10]
char bq_queue_id[10]
char bq_queue_fitness[80]
char bq_process_fitness[80]
signal([char* es]) ..................................................... [3.4]
where es structure is
char bq_class_id[10]
char bq_queue_id[10]
3.5.3 PC-Queue and CS-Queue Evolution Scheduling
Evolutionary programming can be used for the queue dispatching
of preference control and priority control. Genetic algorithms are
a better mechanism to replace the FIFO process dispatching of
forerunner controls, preference controls, and priority controls.
3.5.3.1 Monitor
A monitor is a collection of procedures, variables, and data structures
that are all grouped together in a special kind of module or package.
A general monitor is a one-dimensional scheduling device.
However, we improve it to be a two-dimensional scheduling control.
server::
monitor monitor_name
procedure procedure_name [with server_es];
...
end;
end monitor;
client::
monitor_name.procedure_name [with client_es];
where server_es structure is
char bq_default_queue_id[10]
char bq_default_queue_fitness[80]
char bq_default_process_fitness[80]
and client_es structure is
char bq_queue_id[10]
char bq_queue_fitness[80]
char bq_process_fitness[80]
3.5.3.2 Forerunner Controls
Forerunner control is the mechanism to resolve races at the entry
level, among pending communication requests in an entry queue.
Figure 3.5: Forerunner Control
Forerunner control is a one-dimensional scheduling control.
The queuing policy can be any of FIFO, priority, guaranteed, etc.
Now let’s see how to implement GA policy for the forerunner control.
Take the following accept statement as an example.
server::
accept entry_name(in;out)
[with server_es] do ...
client::
task_name.entry_name [with client_es];
where server_es structure is
char bq_default_process_fitness[80]
and client_es structure is
char bq_process_fitness[80]
All we need is to add a parameter of server_es to tell the evolution
scheduler the default process fitness function. If the user program
doesn’t fill in the process fitness, the evolution scheduler can assign
the default value for it.
3.5.3.3 Preference Controls
Preference control is the mechanism to resolve races at the task
level, within a non-deterministic selection construct, among
eligible alternatives.
Figure 3.6: Preference Control
Basically the queue-dispatching mechanism for preference
control can be carried out by any feasible scheduling algorithm,
and the process-dispatching mechanism is generally FIFO.
However, we can implement our evolution scheduling for the
preference control with more flexibility.
server::
select
prefer: HIGH [with high_es]
accept entry_name (HIGH) (in; out)
...
or
prefer: MEDIUM [with medium_es]
accept entry_name (MEDIUM) (in; out)
...
or
prefer: LOW [with low_es]
accept entry_name (LOW) (in; out)
...
end select;
client::
task_name.entry_name (HIGH) (in; out) [with client_es]
where high_es, medium_es, and low_es structures can be
char bq_queue_fitness[80]
char bq_default_process_fitness[80]
and client_es structure is
char bq_process_fitness[80]
3.5.3.4 Priority Controls
Priority control is the mechanism to resolve races at the program
level, among the tasks that are eligible for execution.
Figure 3.7: Priority Control
4 Significance of This Research
Evolution scheduling is very different from traditional scheduling.
Evolving processes and evolution scheduling create four advantages:
[1] Evolving processes and evolution scheduling provide object-oriented
schedulers and processes for programmers. [2] Evolving processes and
evolution scheduling support flexible mechanisms and rich policies for
end-users. [3] Evolving processes and evolution scheduling apply parallel
scheduling, which interests artificial intelligence experts.
[4] Evolving processes and evolution scheduling distribute resources
to waiting processes according to the ratio of each process guarantee
value to the total guarantee values. It should also be noted that
evolving processes and evolution scheduling construct a reactive/adaptive
and reflective artificial intelligence framework for concurrent programming.
In addition, evolving processes and evolution scheduling enable
parallel/concurrent and distributed evolutionary computing on object-oriented systems.
4.1 Object-Oriented Schedulers and Processes
Evolution scheduling treats each scheduler and each process
as an abstraction data type object, which can inherit attributes
from its parents. Evolution scheduling consolidates
[1] the ready-queue scheduler, [2] the blocked-queue scheduler,
[3] the priority-control queue scheduler, and [4] the client-server
queue scheduler into process classes and scheduler classes.
A scheduler class defines any kind of these four schedulers,
and a process class defines all the behaviors of a process.
This provides a way for us to manage and monitor the activities
of processes, and to manipulate the stochastic optimization of
evolutionary computation.
4.2 Flexible Mechanisms and Rich Policies
The evolution scheduler can change its scheduling behavior
at run time, therefore simulating any existing scheduler,
if necessary. This is different from the features provided by
currently existing compilers, which support queuing policies for
programmers during the compilation time.
4.3 Parallel Scheduling
Each process has a chance to be selected with a probability
greater than zero and less than or equal to one. Consequently,
non-deterministic evolution scheduling has distinct advantages
over traditional sequential scheduling. Meanwhile, this
outstanding feature is consistent with operating systems and programming
languages, so we can count on its efficiency and effectiveness.
4.4 Relative Resource Scheduling
Guarantee value ensures that each process has a relative
percentage of shared resources. Relative resource distributions
cannot be initiated by simple priority scheduling, round robin scheduling,
or FIFO scheduling. For a close-looped system, the resources are
limited and valuable. This should be more reliably distributed by
relative percentages than by process priorities, which cannot precisely
define resource dividends.
4.5 Reflective Artificial Intelligence Frameworks
Evolving processes and evolution scheduling
(with the capacity of fitness functions) construct a framework
for reflective computing. All the computational behaviors in an
encapsulated object can be implanted in evolving processes, and
evolution scheduling will assist evolving processes to perform
reflective computing.
4.6 Parallel and Distributed Evolutionary Computing
Evolution scheduling is based on fundamental theorems of
stochastic optimization of evolutionary computation.
Evolutionary computation can definitely share computation loads to
concurrent object-oriented systems with evolution scheduling.
Evolution scheduling takes care of CPU and I/O resources and
evolving processes adjust themselves to adapt to environments
where they live and grow. Evolutionary computation programmers
apply parallel evolutionary algorithms to evolving processes
and evolution scheduling.
5 Conclusions and Further Work
Evolving processes and evolution scheduling have many advantages;
however, they have a disadvantage. The disadvantage is that the
evolution scheduler is a time-consuming one. This is not a fatal issue.
The time-consuming problem can be solved by [1] further simplified genetic
algorithms and evolutionary programming, which will save time in
calculation of algorithms, [2] a faster CPU, which becomes possible
because of the developing hardware improvement in chip technology,
or [3] a slave CPU, which is dedicated to do scheduling and support
part of communication load for a master CPU.
We define evolving processes and evolution scheduling to support
concurrent object-oriented systems and parallel evolutionary computation.
We have presented an efficient and effective solution to implement
reflective computation for concurrent programming languages that fulfill
parallel genetic algorithms on concurrent programming platforms.
There are four ongoing research areas: [1] Simplifying genetic algorithms
and evolutionary programming, [2] reporting empirical results for
evolving processes and evolution scheduling, [3] employing evolving
processes and evolution scheduling to solve classic concurrent
programming problems, and [4] migrating parallel evolutionary
computation to evolving processes and evolution scheduling platforms.
Each of these is currently being investigated by our research group.
References
[1]DeJong, Kenneth A. and Spears, William, "On the State of Evolutionary Computation," kdejong@aic.gmu.edu, George Mason University, Fairfax, VA, 1995.
[2]DeJong, Kenneth A. and Spears, William, "Using Genetic Algorithms to Solve NP-Complete Problems," kdejong@gmuvax2.gmu.edu, George Mason University, Fairfax, VA, 1995.
[3]Elrad, Tzilla and Verun, Ufuk, "Comprehensive Concurrent Controls Classification: Achieving Reflection in Concurrent Object-Oriented Systems," http:// www.iit.edu/~cselrad/, Concurrent Programming Group, Computer Science Department, Illinois Institute of Technology, Chicago, IL.
[4]Fogel, David B., Evolutionary Computation: Toward a New Philosophy of Machine Intelligence, IEEE Press, Piscataway, NJ, 1995.
[5]Gehani, N.H. and Roome, W.D., The Concurrent C Programming Language, Silicon Press, Summit, NJ, 1989.
[6]Heitkoetter, Joerg and Beasley, David, The Hitch-hiker's Guide to Evolutionary Computation, EUnet Deutschland GmbH, Research & Development Technologie Park, D-44227 Dortmund, Germany, 1995.
[7]Kumar, Vipin and Grama, Ananth, Introduction to Parallel Computing Design and Analysis of Algorithms, Benjamin/Cummings Publishing, Menlo Park, CA, 1994.
[8]Singhal, Mukesh and Shivaratri, Niranjan G., Advanced Concepts in Operating Systems: Distributed, Database, and Multiprocessor Operating Systems, McGraw-Hill Companies, New York, NY, 1995.
[9]Tanenbaum, Andrew S., Operating Systems Design and Implementation, Prentice-Hall, Englewood Cliffs, NJ, 1994.
[10]Trivedi, Kishor S., Probability & Statistics with Reliability, Queuing, and Computer Science Applications, Prentice-Hall, Englewood Cliffs, NJ, 1995.
[11]Winston, Patrick Henry, Artificial Intelligence, Third Edition, Addison-Wesley Publishing, Reading, MA, 1994.
[12]Zomaya, Albert Y.H., Parallel & Distributed Computing Handbook, McGraw-Hill Companies, New York, NY, 1996.