The Parallel Execution Module defines two application programming interfaces. The first API contains functions of PEM’s upper layer - the user interface layer, whereas the second API contains the interface functions of the lower layer. The functions of the latter are not directly accessible to the application developer, but they are im portant for porting GAME to other operating systems or custom hardware communication support.
M ost o f the functions o f P E M ’s upper layer API take a handle to an entry in the component data base as one of their arguments. A data base entry is created when a new child component is started or a new connection is opened to an already running component. In both cases the ComponentDescriptor structure is required (see Figure 6.11). This structure contains information used by PEM to start a component or establish a connection to a component. The user fills in five fields: component_name, port_name, connection_type, connection_host smd ipc_buf_sz. The last two are optional and assume the local host and a buffer o f 1 Kbytes, by default.
Figure 6.11 - The component data base entry struct ComponentDescriptor
{
char* component_name ; /* path and file name of the con^onent */ char* port_name; /* Server port name */ char* connection_host; /* Host where the server is running */ PCTYPE connection_type; /* Type of connection (LOCAL/EXTEHNAL) */ HANDLE hIpcComp; /* Handle provided by the IPG object */ HANDLE hIpcConn; /* Handle to the IPG channel object */ WORD ipc_buf_sz; /* Size of the communication buffer */
ComponentDescriptor (void);
ComponentDescriptor (const ComponentDescriptor FARfi); virtual -ComponentDescriptor(void);
virtual Con^onentDescriptor& operator- (const Con^onentDescriptor FAR&); };
6.6. Summary
The first section of this chapter reviewed three common software strategies used to support parallel program m ing, namely: language-based, operating system -dependent and language/operating system independent parallel support. The discussion of each one of these strategies was based on currently available programming languages and software systems, and permitted to assess their strengths and weaknesses. This study led to the definition o f GAM E’S parallel programming model and its implementation support - the Parallel Execution Mcxlule.
g a m e’s programming model was then introduced, and its message-passing architecture described. The programming model defined for the system is highly flexible, supporting the im plem entation of com plex parallel applications, based on a language/operating system
independent strategy. This alternative was elected since it offers the required degree of portability for applications created with GAME.
The explanation of the messaging sub-system, and its implementation, was followed by the description of the Parallel Execution Module. The design of PEM’s internal structure, which comprises two independent implementation layers (the upper and the lower layers), clearly demonstrated the concern with application and system portability. The definition of an apphcation programming interface for the upper layer ensures platform independence for applications. In the same way, an API between the upper and lower layer facilitates the porting of GAME, without affecting apphcations’ design and implementation.
Finally, it is important to stress that GAME’S programming model and its underlying support are, together, a powerful tool for the creation of parallel applications. They have been designed to cater for a much broader range of parallel applications and therefore, are not limited to supporting genetic algorithms.
Chapter 7
The GAME Libraries
The GAME Libraries comprise two principal groups o f C++ class libraries. This chapter describes the organisation and implementation o f the Genetic and Service libraries.
7.1. Introduction
Development environments are complex software systems designed to provide as much flexibility and reliability as possible for application developers. Among the standard set of tools generally available in a programming environment, a collection of runtime libraries constitutes one of the most important assets for software developers. Runtime libraries are normally supplied with a variety of general-purpose functions that help to reduce the time required to implement applications, freeing the programmer to concentrate on the details of the application design. Operations such as formatted input and output, floating-point and complex arithmetic, graphic display, and interactions with the operating system’s services are now commonly available in any programming environment. More recently, a new generation of “class libraries” has appeared, based on the object-oriented paradigm . Such libraries offer even more flexibility for the programmer, by allowing the customisation of one or all its member functions and member data, via inheritance and overloading mechanisms.
Programming environments for applications based on genetic algorithms must also offer a comprehensive collection o f libraries, possibly containing parameterised versions of standard sequential and parallel G As and genetic operators. According to the general model of a GA-based application, it is possible to define a set of parameterised GA libraries. Typically, an application is organised in three hierarchical levels:
• the Application Domain level, comprising domain-specific applications (e.g. finance, telecommunications, etc.);
• the A lgorithm Class level, with a variety o f algorithm s grouped into categories (scheduling, routing, etc.) to be used in applications; and
• th e G e n e tic O p er a to r l e v e l , e n c o m p a s s in g a n u m b e r o f g e n e t ic o p e r a to r s to b e incorporated into different algorithm s.
A s e c o n d g r o u p o f lib r a r ie s c o n t a i n i n g a u x ilia r y f u n c t i o n s to b e u s e d in th e im p le m e n ta tio n o f G A s and their g e n e tic op erators m ay a lso b e c o n sid e r e d . T h is “a u x ilia r y ” group o f libraries m ight in clude m odu les for en cod in g and d ecod in g g en etic structures (em p loyin g several techniques and alphabets) as w e ll as platform -dependent m odu les su ch as random num ber generators, inter-process com m u n ication support, etc.
T h e G A M E p rogram m ing en viron m en t co m p rises tw o m ain library grou p s, n a m ely the G e n e tic L ib r a r ie s and th e S e r v ic e L ib r a r ie s. T h e s e tw o lib ra r y g r o u p s h a v e b e e n d e f in e d accord in g to the structure ou tlin ed a b o v e. T h e G en etic Libraries p rovid e p aram eterised v er sio n s o f ap p lication s, g en etic algorithm s and operators for a variety o f dom ain s. T h e S erv ice Libraries group, on the other hand, is the repository for the rest o f the en viron m en t’s m od u les. It com p rises the graphic user in terface library, the com m u n ication and parallel control library, the m onitoring library and th e s y ste m lib rary. T h e latter co n ta in s the V irtu al M a c h in e , th e g e n e tic -o r ie n te d represen tation and various an cillary fu n ction s in clu d in g string en co d in g and d eco d in g , m em ory m an agem en t, etc. F igu re 7.1 sh o w s the re la tio n sh ip b e tw e e n the m o d u le s o f a ty p ic a l G A M E application and the various libraries o f the environm ent.
T h e G A M E L ib r a r ie s h a v e b e e n d e s ig n e d to p r o v id e th e m a x im u m f l e x i b i l i t y in c o m b in in g th eir m o d u le s in to a lg o r ith m s and a p p lic a tio n s . F u rth erm ore, th e y ca n be e a s ily expanded w ith the in clusion o f n ew m odules.
Figure 7.1 - Application and libraries
Application Library Algorithms Library Operators Library ( iv V M i: A p p l l t s i t b i i Gen^ AJgâHthi» y/j Selection ji Crossover J Mutation 1
ParalQel Support Module
Population Fitness Manager Evaluator Graphics Library Monitoring Library ConuDS& Parallel Control System Library T h er e is , h o w e v e r , a fu n d a m e n ta l d iff e r e n c e b e tw e e n th e s e tw o g ro u p s o f lib ra r ie s rela tin g to the w a y their m o d u le s are co n stru cted . T h e G e n e tic L ibraries c o n ta in o n ly G A M E C o m p o n e n ts, i.e ., m o d u le s that ca n b e eith er sta n d -a lo n e e x e c u ta b le s or d y n a m ic a lly lin k e d (D L L s) w ith other D L L s or e x e c u ta b le s. C o n v e r se ly , the S e r v ic e L ib raries are a c o lle c tio n o f
Chapter 7___________________________ The GAME Libraries___________________________ 131
modules designed to be statically linked into executables or DLLs like GAME Components. This distinction stems from GAME’S programming model, which requires GAME Components to be dynamically interconnected by apphcations.
M odules from the G enetic L ibraries, although including stand-alone executable programs, still fit in the traditional concept o f a library module since they cannot provide any useful functionality unless “connected” to other modules (DLLs or other executables). A genetic algorithm component (as an executable module), for instance, needs at least some genetic operators (either as DLLs or stand-alone executables) and the Virtual Machine to perform any useful computation. The major advantage of this library approach is the ability to construct entirely new applications and genetic algorithms without needing to re-compile or re-link any piece of object code. A simple configuration file, as shown in Chapter 6 (Figure 6.10), provides the necessary information to put together parameterised genetic operators, algorithms (= Virtual Machine + genetic operators + parameters) and applications (= algorithms + user interface + parameters).
The next sections discuss in more detail the parameterisation of genetic algorithms and describe some modules of GAME’S Genetic and Service Libraries.