8 pages

English

Tutorial AFPAC

Siom

Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres

8 pages

English

Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres

A propos
Informations
Extrait

Description

AFPACAdaptation Framework for Parallel ComponentsCoordinator tutorialJeremy BuissonContents1 Runtime architecture 12 Initialization of the coordinator component 22.1 Manual initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.1 ORB initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2 Thread management library initialization . . . . . . . . . . . . . . . . . . . 32.1.3 Communication library initialization . . . . . . . . . . . . . . . . . . . . . . 32.1.4 Instantiation of the coordinator object . . . . . . . . . . . . . . . . . . . . . 32.2 Automated initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Designing an action 43.1 Greeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Initialization of the action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Finalization of the action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Finalization of the coordinator component 64.1 Manual nalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64.1.1 Destruction of the coordinator object . . . . . . . . . . . . . . . . . . . . . 64.1.2 Finalization of the communication library . . . . . . . . . . . . . . . . . . . 64.1.3 Finalization of the thread management library . . . . . . . . . . . . . . . . 64.1.4 ORB nalization . . . . . . . . . . . . . . . . . . ...

Informations

Publié par	Siom
Nombre de lectures	11
Langue	English

Extrait

AFPAC Adaptation Framework for Parallel Components Coordinator tutorial

Contents

Runtime architecture

J´er´emyBuisson

Initialization of the coordinator component 2.1 Manual initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 ORB initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Thread management library initialization . . . . . . . . . . . . . . . . . . . 2.1.3 Communication library initialization . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Instantiation of the coordinator object . . . . . . . . . . . . . . . . . . . . . 2.2 Automated initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Designing an action 3.1 Greeting action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Initialization of the action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Finalization of the action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Finalization of the coordinator component 4.1 Manual ﬁnalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Destruction of the coordinator object . . . . . . . . . . . . . . . . . . . . . 4.1.2 Finalization of the communication library . . . . . . . . . . . . . . . . . . . 4.1.3 Finalization of the thread management library . . . . . . . . . . . . . . . . 4.1.4 ORB ﬁnalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Automated ﬁnalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bindings for other languages 5.1 Initialization of the Fortran binding library . . . . . . . . . . . . . . . . . . . . . . 5.2 Functions accessible from Fortran code . . . . . . . . . . . . . . . . . . . . . . . . .

Runtime architecture

2 2 2 3 3 3 4

4 4 5 5

6 6 6 6 6 7 7

7 7 7

Figure 1 shows the runtime architecture of the coordinator component within the processes of the service. Theafpac::coordinator::MuxCoordinatorclass plays the role of a facade for the coordinator component. Theafpac::toolsnamespace contains the expected interfaces for encapsulating third-party libraries (communication and thread management). At runtime, the coordinator component is physically distributed over the collection of pro-cesses used by the service. Each process of the service component must have its own instance of theafpac::coordinator::MuxCoordinatorclass. The general approach for the coordinator component is hierarchical: each process has one singleton instance for the every threads it con-tains. However, at the current state, the coordinator component is not able to manage several threads in one process. Processes are thus restricted to contain exactly one execution thread

Figure 1: Runtime architecture of the coordinator

for the service. Nevertheless, shared memory across process boundary can be used to simulate two-level parallelism (processes as collections of threads).

Initialization of the

coordinator component

In order to initialize itself, the coordinator component of the AFPAC framework requires that its dependencies are already initialized. Dependencies include the CORBA-compliant object re-quest broker, the global communication library and the thread management library. The AFPAC framework does not impose any order for initializing its dependencies. However, as it is the case in the given examples, dependencies may appear for example from the communication library to the thread management library.

2.1 Manual initialization 2.1.1 ORB initialization The initialization of the ORB implementation should be done in a standard way. In addition to initializing the ORB object, the component should activate the root portable object adapter. The following code snippet can be used:

1 2 3 4 5

1 2

1 2 3 4

CORBA : : ORB var o r b = CORBA : : ORB init ( a r g c , a r g v ) ; CORBA : : O b j e c t v a r o b j = orb−>i n i t i a l r e f e r e n c e s ( ”RootPOA” ) ;r e s o l v e P o r t a b l e S e r v e r : : POA var poa = P o r t a b l e S e r v e r : : POA : : n a r r o w ( o b j ) ; P o r t a b l e S e r v e r : : POAManager var pman = poa−>( ) ;the POAManager pman−>a c t i v a t e ( ) ;

This code is standard for CORBA applications and does not require any particular comment. In particular, it should not be forgotten to have one thread invoking theCORBA::ORB::runmethod. Further explications can be found in usual CORBA documentations and tutorials.

2.1.2 Thread management library initialization The coordinator component of the AFPAC framework sees the thread management library as an object that implements theafpac::tools::ThreadFactoryinterface. As for the communication library, this interface deﬁnes the basic operations (thread creation, monitor creation and thread-local storage creation). Again, the initialization depends on the actual thread management library and its encapsulation with AFPAC interfaces. For example, the default AFPAC encapsulation of the PThread library is initialized with the following code snippet: a f p a c : : t o o l s : : p t h r e a d : : T h r e a d F a c t o r y∗t f = newa f p a c : : t o o l s h r e a d F a c t o r y : : T p t h r e a d : : ;

2.1.3 Communication library initialization As seen by the coordinator component of the AFPAC framework, initializing the communication library means obtaining an object that implements theafpac::tools::Communicatorinterface. This interface deﬁnes the basic operations the framework relies on (barrier and global data ex-change). Obtaining such an object is strongly dependent on the actual communication library and its encapsulation with AFPAC interfaces. For example, with the SC toolbox for encapsulating a MPI implementation, the initialization can be done with the following code snippet: s c : : mpi : : CommunicatorFactory∗c f = new) ;: : mpi : : CommunicatorFactory ( t f s c c f−>) ;, a r g v ( a r g c i n i t i a l i z e a f p a c : : t o o l s : : Communicator∗f= c w o r l d −>getWorld ( ) ;

In line 1, the communication library object is created thanks to the SC toolbox. This library is initialized in line 2: it consists in executing theMPI_Init_threadfunction then setting up the real world communicator object. In line 3, the world communicator object is extracted from the communication library.

2.1.4 Instantiation of the coordinator object Once its dependencies are satisﬁed, the coordinator object can be instantiated. In the architecture of the AFPAC framework, the coordinator component is distributed over the processes of the component. This means that each process must create its own instance of the coordinator object. This is done thanks to the following code snippet: a f p a c : : I D e c i d e r G a t e w a y v a r i d e c i d e r = a f p a c : : t e s t s : : d e c i d e r : : g e t D e c i d e r G a t e w a y ( orb , a r g c , a r g v ) ; c o o r d i n a t o r = newc o o r d i n a t o r : : a f p a c ) ;d e c i d e r , i , orb , world : : MuxCoordinator ( t f

In line 1, command line arguments are searched for a reference to the executor component. In line 3, the actual coordinator object is instantiated. Once this instruction has been executed, the coordinator component of the AFPAC framework is up and ready to be used.

1 2 3 4 5 6 7 8 9 10 11 12

1 2 3 4

1 2 3

2.2 Automated initialization Alternatively to manually initialize each library, AFPAC comes with a template function that instantiate every required objects. The complete initialization is done thanks to the following single code snippet: CORBA : : ORB var o r b = CORBA : : ORB : : n i l ( ) ; P o r t a b l e S e r v e r : : POA var poa = P o r t a b l e S e r v e r : : POA : : n i l ( ) ; a f p a c : : t o o l s : : T h r e a d F a c t o r y∗= NULL ;t h r e a d s a f p a c : : t o o l s : : CommunicatorFactory∗;= NULL c o m m u n i c a t i o n s a f p a c : : t o o l s : : Communicator∗w o r l d = NULL ; a f p a c : : t o o l s : : Runner∗r u n n e r ;= NULL

a f p a c : : c o o r d i n a t o r : : MuxCoordinator∗c o o r d i n a t o r = a f p a c : : i n i t i a l i z e <: : t o o l s a f p a c : : Thre adFac t or y : : p t h r e a d , s c : : mpi : : CommunicatorFactory>,, argv ( a r g c h r e a d s , t , poa , orb c o m m u n i c a t i o n s , world , r u n n e r ) ;

The singleafpac::initializefunction initializes the ORB implementation, activates the CORBA portable object adapter, initializes the thread management library, spawns a thread that executes theCORBA::ORB::runmethod, initializes the communication library, extracts from the communication library an encapsulation object for the world communicator, retrieves from command-line arguments the reference to the decider object and instantiates the coordinator fa-cade object. Once this method has returned, the coordinator component of the AFPAC framework is up and ready to be used.

Designing an action

With the current implementation, the purpose of the coordinator component consists in executing parallel actions in the context of the execution threads of the service. The actions are executed from adaptation points, with the property that an action is always executed from the same adaptation points by all execution threads of the service. An action is exposed to the AFPAC coordinator component as an instance of a class that realizes theafpac::coordinator::Reactiondo so, the action must implement theinterface. To afpac::coordinator::Rection::executemethod. This method should implement the reception of an invocation message for the action. This message, which can be compared to a reiﬁed function call, contains the name of the invoked action and eﬀective parameters for this action.

3.1 Greeting action Within this tutorial, the example of a simple greeting action is detailed. This action welcomes a person whose name is given as a parameter. The source code of the action is the following one: a f p a c : : r e a c t i o n s t a t u s t g r e e t i n g ( s t d : : s t r i n gconst)& name { s t d : : c o u t<<”Welcome , ”<<name<<s t d : : e n d l ; returna f p a c : : CONTINUE; }

Now that the source code of the action has been written, the treatment of the reiﬁed call has to be done. The class is declared as follows: c l a s sG r e e t i n g A c t i o n :i r t u a lpublic v c o o r d i n a t o r : : R e a c t i o n: : a f p a c { public: G r e e t i n g A c t i o n ( ) ;

4 5 6 7 8

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

1 2 3

v i r t u a l˜ G r e e t i n g A c t i o n ( ) ; v i r t u a ltr e a c t i o n s t a t u s : : a f p a c e x e c u t e (char const∗name , a f p a c : : p a r a m e t e r s tconst& params ) ; };

Theexecutemethod is implemented as shown in the following code snippet: a f p a c : : r e a c t i o n s t a t u s t G r e e t i n g A c t i o n : : e x e c u t e (char const∗name , a f p a c : : p a r a m e t e r s tconst& params ){ s t d : : s t r i n g g r e e t i n g n a m e = ” g r e e t i n g ” ; i f)== name n a m e r e e t i n g ( g { s t d : : s t r i n g p name ; boolp n a m e h a s =f a l s e; f o r(CORBA : i = 0 : ULong ; i<params . l e n g t h ();++ i ){ s t d : : s t r i n g param name = params [ i ] . name ; i fa m e ==( ( h a s p n f a l s eparam name == ”name” ) )) && ( { char const∗;s t r p [ i ] . v a l u e>>= s t r ; p name = s t r ; h a s p n a m e =true; } } i f)p n a m e ( h a s { returng r e e t i n g ( p name ) ; } } return: : CONTINUE;a f p a c }

This method ﬁrstly checks for the name of the action. Then it collects the eﬀective parameters for the action. Endly, it calls the action function. Although it would appear useful, the current AFPAC distribution does not include any tool to generate automatically the code that invokes actions from the reiﬁed forms of the invocations. However, in the future of AFPAC, such a tool may be design to generate the action class auto-matically from the signature of several action functions.

3.2 Initialization of the action Writing the source code of an action is not suﬃcient. The action must be made available to the AFPAC coordinator component. To do this, the coordinator component exposes a reaction repository. This object is a mapping from action name to the object that implements the action. Initializing the greeting action is done thanks to the following code snippet: G r e e t i n g A c t i o n∗a c t i o n =newG r e e t i n g A c t i o n ; s t d : : s t r i n g a c t i o n n a m e = ” g r e e t i n g ” ; c o o r d i n a t o r−>n a m e , a ( a c t i o n c t i o n ) ;r e g i s t e r R e a c t i o n ( ) . r e a c t i o n s

Once this has been executed, the coordinator component becomes able to execute the greeting action.

3.3 Finalization of the action Before destroying the action object, the coordinator component must be told not to use it anymore. Like for the initialization, this is done through the reaction repository. The following code snippet

1 2 3

1 2

destroys the greeting action: s t d : : s t r i n g a c t i o n n a m e = ” g r e e t i n g ” ; c o o r d i n a t o r−>r e a c t i o n s u n r e g i s t e r R e a c t i o n ( ) . c t i o n ( a ) ;n a m e d e l e t ea c t i o n ;

Finalization of the

coordinator component

In order to ﬁnalize the coordinator component, the corresponding object has to be destroyed. Once this has been done, dependencies of the coordinator component (object request broker, communication library and thread management library) can be safely ﬁnalized.

4.1 Manual ﬁnalization 4.1.1 Destruction of the coordinator object Each coordinator object of the coordinator component can be destoyed independently of the others. This means that processes are not required to terminate at the same time. However, objects scheduled for destruction must have been previously removed from the collection of coordinator objects. This can be done thanks to the method: voidc o o r d i n a t o r : : MuxCoordinatora f p a c : : : : r e c o n n e c t ( a f p a c : : t o o l s : : Communicator∗) ;w o r l d

This method notiﬁes the coordinator component that the set of processes changes. The actual destruction of the coordinator object is done thanks to the following code snippet: d e l e t ec o o r d i n a t o r ;

Indeed, the destructor of theafpac::coordinator::MuxCoordinatorreleases the resources used by the coordinator object. Once the destructor returns, the local process does not participate to the coordinator component anymore. Its dependencies can be safely ﬁnalized.

4.1.2 Finalization of the communication library The ﬁnalization of the communication library depends on the library itself. However, whatever the used library, the encapsulation object behind theafpac::tools::Comunicatorcan be destroyed. In the example of using the SC toolbox for encapsulating MPI, the following code snippet ﬁnalizes the communication library: d e l e t ew o r l d ; d e l e t ec f ;

In this case, the world communicator object has to be explicitely destroyed as its ownership has been requested in the initialization phase (use of thegetWorldthemethod). Destroying communicator factory makes the SC toolbox call theMPI_Finalizefunction that releases resources used by the MPI implementation library.

4.1.3 Finalization of the thread management library Similarly to the communication library, the ﬁnalization of the thread management library mostly consists in destroying the encapsulation objects. When using the default AFPAC encapsulation of the PThread library, the following code snippet can be used: d e l e t e;t f

The destructor almost does nothing except releasing some memory.

1 2 3

1 2

1 2 3 4 5 6 7

4.1.4 ORB ﬁnalization Finalizing the CORBA object request broker should be done in the usual way: the portable object adapter should be deactivated; then the object request broker should be destroy. This is done by the following code snippet: pman−>d e a c t i v a t e ) ;( 0 , 1 orb−>shutdown ( 1 ) ; orb−>d e s t r o y ( ) ;

Further details can be found in usual CORBA documentations and tutorials.

4.2 Automated ﬁnalization Alternatively to the previous manual clean-up, AFPAC comes with a function that ﬁnalizes the runtime environment with one single call. The following single code snippet can be used: a f p a c : : f i n a l i z e ( orb , poa , t h r e a d s , c o m m u n i c a t i o n s , world , c o o r d i n a t o r , r u n n e r ) ;

This single function ﬁnalizes everything that is initialized by theafpac::initializefunction.

Bindings for other languages

The coordinator component must be instantiated within the processes of the service component. As the coordinator component is written in C++, it can not be accessed directly from other languages, including C, Fortran and Java. Some binding library has to be used in each case. The AFPAC coordinator component comes with a binding library for Fortran. This library bridges function calls from the fortran code to method invocations sent to an instance of the afpac::coordinator::MuxCoordinatorclass that facades accesses to the coordinator compo-nent. At the current state, this library is minimalist. It does not allow to directly initialize the coordinator component from the fortran code; neither it allows to write reactions entirely in fortran.

5.1 Initialization of the Fortran binding library The fortran binding library does not rely on the theafpac::coordinator::MuxCoordinator singleton object. The library has its own global variable for storing the facade object that should be used. This variable is hidden. However, it can be set thanks to the following global function: voidc o o r d i n a t o r : : MuxCoordinatorf o r t r a n : : a f p a c : : f p a c : : s e t u p ( a ∗) ;f a c a d e

If the global variable is assigned with a null pointer (initial value), the fortran binding is deacti-vated. In such a case, calls from fortran code are sunk.

5.2 Functions accessible from Fortran code The binding library deﬁnes the following functions for accesses from Fortran code: function( )a f p a c i n i t i a l i z e d subroutine( )a f p a c p o i n t subroutinef u n c t i o n a f p a c (e n t e r name) subroutinef u n c t i o n l e a v ea f p a c function( c )c o n d i t i o n e n t e r a f p a c subroutine( )l e a v e c o n d i t i o n a f p a c subroutine( )e n t e r l o o p a f p a c

8 9 10 11

subroutine subroutine function function

a f p a c l o o p i t e r a t e i ( i ) a f p a c l o o p i t e r a t e r ( i ) a f p a c l o o p w h i l e ( c ) a f p a c f a s t f o r w a r d

The ﬁrst functionafpac_initializedchecks whether the fortran binding is active; the others functions directly maps to the methods of the coordinator component.