tutorial

Informations

• Publié par: Licod
• Nombre de lectures: 15
• Langue: English

Extrait

AFPAC / SC toolbox
Adaptation Framework for Parallel Components
Spawning Communicators tutorial
Jeremy Buisson
Contents
1 Introduction 1
2 Communicator objects 1
2.1 Initialization of the toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Bootstrap of the rst communicator object . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Destruction of a communicator object . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Finalization of the toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Spawn processes 3
3.1 Spawn sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Spawner object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Process creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Disconnect processes 5
5 Architecture 6
1 Introduction
Thespawningcommunicators(SC)toolboxhasbeendesignedinordertode neauniforminterface
forglobalcommunicationswithinacollectionofcooperatingprocesses. Thosecommunicationsare
done through communicator objects. Whereas the interface dened in AFPAC declares operations
usedbyAFPAC(synchronizationbarrierandvaluegathering),SCde nesaninterfacefordynamic
process management.
Dynamic process management, in the case of global communications, is understood by SC as
the ability to make the collection of cooperating processes grow or shrink at runtime. Make the
collectiongrowmeansspawnnewprocessesandproduceacommunicatorobjectthatconnectsboth
spawned processes and previously existing processes. Make the collection shrink means produce a
communicator object that connects only a subset of previously connected processes, allowing the
others to terminate independently.
In addition to interfaces, SC comes with a reference implementation on top of MPI-2.
2 Communicator objects
The SC toolbox relies on the abstract concept of communicator objects. This concept is almost
the same as communicators of MPI: communicator objects can be seen as a generalization of
unicast sockets that connectn endpoints. The endpoints connected to a communicator object are
not di erentiated. Communicator objects de ne a set of collective operations, which involves all
1endpoints connected to the target object. Such operations include synchronization barrier, value
gathering and so on. As de ned by SC interfaces, communicators object are immutable, meaning
that the collection of endpoints connected to an object is not allowed to change. However, in
order to support dynamic process management, communicator objects support two operations
that produce new communicator objects: spawning and disconnecting process.
2.1 Initialization of the toolbox
Before communicator objects can be retrieved and used, the SC implementation must be initial-
ized. The toolbox itself is encapsulated in a class that implements the sc::CommunicatorFactory
interface. This class depends on the communication library encapsulated in the SC implementa-
tion. With the MPI-2 reference implementation, the toolbox is initialized with the following code
snippet:
1 sc ::mpi:: CommunicatorFactory cf =
2 new sc ::mpi:: CommunicatorFactory( tf );
3 cf >initialize (argc , argv );
Inthesc::CommunicatorFactory::initializemethod, theMPI-2referenceimplementation
calls the MPI_Init_thread function. It requests the MPI_THREAD_MULTIPLE level for thread sup-
port. This implementation depends on a thread management library for avoiding race conditions.
It uses the interface dened by AFPAC.
2.2 Bootstrap of the rst communicator object
Oncethetoolboxhasbeeninitialized,communicatorobjectscanbeused. Nevertheless,areference
to a rst communicator object must be obtained. During its initialization, the toolbox creates two
special communicator objects:
the “self” communicator object to which only the local process is connected;
the “world” communicator object to which processes spawned together are all connected
with their spawning processes.
Those two special communicator objects are owned by the communicator factory object encapsu-
lating the toolbox.
Clonesofthosespecialcommunicatorobjectscanbeobtainedwiththefollowingcodesnippet:
1 afpac :: tools ::Communicator self = cf >createSelf ();
2 afpac :: tools ::Communicator world = cf >createWorld ();
However, as those methods only return clones, destroying the special communicator objects can
not be done directly.
The communicator factory object provides with methods for explicitely destroying the special
communicator objects as shown by the following code snippet:
1 cf >releaseSelf ();
2 cf >releaseWorld ();
Once those methods return, the special communicator objects are destroyed. Thus, subsequent
invocations of the createSelf or createWorld methods fail. Nevertheless, previously created
communicator objects (for example as results of those methods) are still valid.
Alternatively to cloning then destroying the special communicator objects, the communicator
factoryobjectisabletoabandonitsownership,makinguobjectsloosetheir“special”
quali er. This can be done with the following code snippet:
1 afpac :: tools ::Communicator self = cf >getSelf ();
2 afpac :: tools ::Communicator world = cf >getWorld();
2As the communicator factory object abandon its ownership, subsequent invocations of any of the
createSelf, createWorld, getSelf or getWorld methods fail.
Whereasownershipabandonmentissemanticallyequivalenttoclonethendestruction,itshould
be prefered. Indeed, ownership abandonment is guaranteed to occur without any communication.
In facts, with the MPI-2 reference implementation, cloning and destroying a communicator object
are both collective operations.
The SC interfaces do not de ne any constant communicator object (as it is the case in MPI-2
with MPI_COMM_SELF and MPI_COMM_WORLD constants). Once the special communicator objects
are destroyed, it becomes impossible to recreate them.
2.3 Destruction of a communicator object
When a communicator object is no more needed, it can be destroyed. In addition to releasing the
associated resources, this action disconnects the endpoints of the communicator object, making
them independent. The following code snippet destroys a communicator object:
1 delete world;
WiththeMPI-2referenceimplementationofSC,thedestructorofthesc::mpi::Communicator
class is a collective operation.
2.4 Finalization of the toolbox
Once the SC toolbox is no more needed, it can be nalized. This action releases the resources
used by the toolbox. In addition, it ensures that the special communicator objects are destroyed,
making processes independent. The following code snippet nalized the toolbox:
1 cf >finalize ();
2 delete cf ;
Once SC has been nalized, it is no more available, not even by creating a new instance of a
class implementing the sc::CommunicatorFactory and invoking its initialize method.
3 Spawn processes
Spawning processes means create new processes. In order to make those new processes cooperate
with the processes that create them, the whole collection of processes must be connected through
a single communicator object. The spawn collective operation does the both actions: it creates
new processes then build the new global communicator object.
3.1 Spawn sequence
Figure 1 shows the sequence diagram of spawn methods. When invoked, those method rely on a
user-provided object that implements the sc::Spawner interface to create the processes. This ob-
ject is provided by the spawn method with an object that implements the sc::EffectiveSpawner
interface. This object contains the code to create a process with which the underlying communi-
cation library is able to establish some link.
Things can be summerized as follows: the user code uses the high-level spawn method of the
sc::Communicator interface to start the spawn. It gives this method an object that implements
the sc::Spawner interface that has the user-level knowledge of details such as executable le
name and command-line arguments. This method is in turn given by the spawn method an object
that implements the sc::EffectiveSpawner that encapsulates the process creation functionality
speci cally for the SC implementation. Endly, the spawn method makes use of its knowledge of
this last object to consolidate the new communicator object.
3Figure 1: Sequence diagram for spawning processes
3.2 Spawner object
Theeasiestwaytowriteaclassthatimplementsthesc::Spawnerinterfaceistousethesc::SetupSpawner
partial implementation. This class implements the spawn methods with a hook to set the name
of the executable le, the command-line arguments and environment variables. Such a class can
be declared as follows:
1 class SimpleSpawner: public virtual sc :: SetupSpawner {
2 private:
3 std :: string const& executable ;
4 sc :: Spawner :: parameters t const& arguments;
5 sc :: Spawner :: environ t const& environment;
6 public:
7 SimpleSpawner(std :: string const& executable ,
8 sc :: Spawner :: parameters t const& arguments ,
9 sc :: Spawner :: environ t const& environment );
10 virtual ˜SimpleSpawner();
11 protected:
12 virtual void setup(std :: string& executable ,
13 sc :: Spawner :: parameters t& arguments ,
14 sc :: Spawner :: environ t& environment );
15 };
T