8.0 Implementation model

When a user asks a class object to create an instance on another host (Figure 6, step 1), the class must do the following

Figure 6 shows the different steps in the procedure. There are different implementation objects for different architectures, and each class maintains implementation objects for all of the architectures on which it might run its instances.

Figure 6Legion object creation

When the class object asks the host object to start an instance, it includes, as a parameter of the create_instance() call, the LOID of the implementation object that shares the same architecture as the host (Figure 7, step 1).

Host object Beta must now find a copy of the appropriate implementation object, which is stored on its associated vault (Figure 7, step 2). It will therefore need to track down the implementation object's LOID on Alpha and make a binary copy of the object for its vault (step 3). Beta can then run the copy to activate an instance of the calling class (step 4).

8.1 Implementation caches
Figure 7Use of the implementation object

While this procedure is a reasonable investment the first time a host object requires a particular implementation object, it becomes expensive over time. Implementation caches avoid repetitive searches for the same implementation objects by acting as an intermediary between the host object and the class object. In Figure 8, when ClassFoo asks host object Beta to create instance Foo using ImplementationObjectX the host object asks its implementation cache to find a copy of X. In this case, Beta's associated Vault already has a copy, so there is no need to contact host object Alpha. If the cache is unable to find a copy of the implementation object on its vault, it will contact Alpha and make a copy for its host object's associated vault.

Figure 8The implementation cache
8.2 Implementation tools

When new host objects are added, the legion_init_arch tool will register implementation objects of that architecture for commonly used classes and objects. The tool is run on the new host, so as to create the objects in the proper place. The sample below was run on a Linux host.

$ legion_init_arch
Initializing Legion implementations for "linux"
 
Creating an implementation (ContextObject) for ContextClass
Continue (y=yes, Y=yes to all, n=no, N=no to all, v=verbose, 
	V=verbose all)? Y
Creating an implementation (MetaClassObject) for LegionClass
Creating an implementation (ClassObject) for VanillaMetaClass
Creating an implementation (BindingAgent) for BindingAgentClass
Creating an implementation (BasicFileObject) for BasicFileClass
Creating an implementation (ttyObject) for ttyObjectClass
Creating an implementation (StatTreeObject) for StatTreeClass
$

Implementation objects for a specific binary executable can be created with the legion_create_implementation utility. The resulting implementation object is marked as usable for specific architectures. Usage of the tool is as follows.

legion_create_implementation
<binary path name> <architecture>
{-l <class LOID> | -c <class context path>}
[-c <context path>] [-nc] [-help] [-v]
[-a <attribute>]

Currently, possible architectures are

A new implementation object created with this tool will be associated with the class object named in <class LOID> or <context path>.

The /impls context contains a list of default implementation objects. The list will look something like this:

$ legion_ls -la /impls
.					(context)
..					(context)
AuthenticationObject.linux.1		(implementation)
BasicFileObject.linux.1 		(implementation)
BatchQueueClassObject.linux.1		(implementation)
BindingAgent.linux.1			(implementation)
ClassObject.linux.1			(implementation)
JobProxyObject.linux.1 			(implementation)
MetaClassObject.linux.1			(implementation)
StatTreeObject.linux.1			(implementation)
StatelessProxyClassObject.linux.1	(implementation)
legion_make_backend.linux.1		(implementation)
ttyObject.linux.1			(implementation)
$

In this example, the default context names for all implementation objects are made up of a class name, architecture, and encoded architecture number (i.e., if 1 is in the name, it is the first implementation object of that architecture for that class).

The example below creates an implementation object for my_class, using Linux, and has the binary path name of my_obj. The new object will automatically be assigned the context path /impls/my_obj.linux.1.

$ legion_create_implementation Legion/bin/linux/my_obj \
   linux -c my_class

If you ran the example a second time, the new object would be called /impls/my_obj.linux.2. You can use the -c flag to specify a different context path or the -nc flag to specify that no context path be assigned. You can also assign the new object extra attributes with the -a flag.

Use legion_list_implementations to see which implementation objects have been assigned to a particular class.


Back to System Administrator Manual Table of Contents

Directory of Legion 1.5 Manuals