Evolutionary Computation for Scheduling Controls
in Concurrent Object-Oriented Systems


This paper has been accepted by CAINE-97 (ISCA 10th INTERNATIONAL CONFERENCE ON COMPUTER APPLICATIONS IN INDUSTRY AND ENGINEERING).

Also, it will be published for the September (or June), 1998 issue of International Journal of Computers and Their Applications (IJCA).



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 VariablesDescription
es_cputotal cpu usage
es_cpu_syscpu used by system processes
es_cpu_idlecpu unused
es_loadsystem load
es_procnumber of processes
es_contextnumber of context switches
es_swapamount of swapping
es_pageamount of paging
es_diskamount of disk accesses
es_intrnumber of interrupts
es_mem_freemb amount of free memory
es_mem_usedmb 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 SchedulingGenetic AlgorithmsEvolutionary Programming
DispatchingProcess DispatchingQueue Dispatching
SchedulingIntra-Queue SchedulingInter-Queue Scheduling
RecombinationYesNo
MutationYesYes
Selection MethodHighest FitnessFitness + 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 QueuesReady QueuesBlocked QueuesPC QueuesCS Queues
Scheduling LevelsOperating SystemOperating SystemProgramming LanguageProgramming Language
Scheduling UnitsOperating System SchedulerSystem Scheduling RoutinesProgramming Language SchedulerServer Process
Scheduler ResponsibilityActivePassiveActivePassive
Resource ScheduledCPUI/O DeviceBlocked QueueService
General Scheduling ControlsRoundRobin, Priority, etc.FIFOPriority ControlsForerunner & Preference Controls
Scheduler ImplementationRequiredRequiredOptionalRequired
Evolution Scheduling ApplicableYesYesYesYes

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
MechanismsEvolution SchedulingTraditional Scheduling
Features of MechanismsFlexibleFixed
Stackable Building BlocksNoYes
Scheduling MechanismsEvolution SchedulingFIFO, Priority Scheduling
When to Determineat Run Timeat 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
PoliciesEvolution SchedulingTraditional Scheduling
Number of SelectionsRich (Many)Limited (Two)
Where to Declare (Generally)in ProcessesCompiling 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 SchedulingQueue DispatchingProcess Dispatching
Round Robin SchedulingN/ARound Robin (FIFO)
Priority SchedulingPriorityFIFO
Multiple Queue SchedulingPriorityFIFO
Shortest Job First SchedulingN/AShortest Job First
Guaranteed SchedulingN/AGuaranteed CPU Time
Two-Level SchedulingPriorityFIFO
Evolution SchedulingEvolutionary ProgrammingGenetic 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 SchedulingQueue DispatchingProcess Dispatching
FIFON/AFirst In First Out
Evolution SchedulingEvolutionary ProgrammingGenetic 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 SchedulingQueue DispatchingProcess Dispatching
Forerunner ControlN/AFIFO
Preference ControlPreference (Priority)FIFO
Priority ControlPriorityFIFO
Evolution SchedulingEvolutionary ProgrammingGenetic 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.