10.0 Implementation model

When a user asks a class object to create an instance on another host, the class must do the following:

  • Determine what kind of architecture the new host has,
  • Contact the correct vault object to request persistent storage space,
  • Assign the new object a LOID and an Object Persistent representation Address (OPA: see "Object states," pg. 135 in the Developer Manual for further information), and
  • Contact the correct host object and ask it to start the new object on the host using a particular implementation object.

Figure 7 shows the different steps in the procedure.

Figure 7: Legion object creation

When a class object asks a host object to start an instance (Figure 7 step 4), it gives the host object the LOID for an appropriate implementation object. An implementation object typically contains executable object code for a single architecture and operating system platform, as well as any other information that might necessary for instantiating an object on a particular host object (Java code, Perl script, etc.). 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. The host must have a copy of a appropriate implementation object in order to start the instance.

Figure 8 shows how the host object accomplishes this. When class Foo, sitting on host Alpha, sends a call (step 1) to create instance Foo on Beta, it gives Beta the LOID for ImplementationObjectX. Beta uses the LOID to find ImplementationObjectX on Alpha (step 2) and makes a binary copy for its own vault (step 3). Beta can then create instance Foo (step 4).

Figure 8: Use of the implementation object

10.1 Implementation caches

While this procedure is a reasonable investment if a host object requires a particular implementation object once, it becomes expensive when repeated. An implementation cache circumvents the problem by acting as an intermediary between the host object and the class object. The implementation cache object is responsible for finding and keeping implementation objects on behalf of its host object. We can update the scenario in Figure 8, since Beta can now ask its implementation cache object to locate a copy of ImplementationObjectX, as show in Figure 9, below.

Figure 9: The implementation cache

10.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

You can see existing implementation objects in the /impls context.

$ 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)

The default context names for all implementation objects consist of a class name, architecture, and encoded architecture number (names ending in *.1 are the first implementation object of that architecture for that class).

You can create Implementation objects for a specific binary executable with legion_create_implementation. The new implementation object is marked as usable whatever architecture you specify. The syntax is:

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

Please see page 23 in the Reference Manual for a list of possible <architecture> values and explanation of the flags.

The new implementation object will be associated with the class object named in <class LOID> or <class context path>. You must provide a path for the binary executable that will run on your specified architecture. The new object will be assigned the context path /impls/<class_name>.<architecture>.# unless you specify otherwise in the <object context path> parameter or use the -nc flag.

The example below creates a Linux implementation object for my_class. The new object will automatically be assigned the context path /impls/my_class.linux.1.

$ legion_create_implementation Legion/bin/linux/my_class \
	linux my_class

If you ran the example a second time, the second implementation object would be called /impls/my_class.linux.2.

Use legion_list_implementations to see a list of which implementation objects have been assigned to a particular class. The output will be each object's LOID and architecture. The example below lists seven implementation objects for the tty class.

$ legion_list_implementations -c /class/ttyObjectClass

alpha_linux   1.3933cb3f.08.42000000.000001fc0bc...
solaris       1.3933cb3f.08.51000000.000001fc0bc...
sgi           1.3933cb3f.08.92000000.000001fc0bc...
rs6000        1.3933cb3f.08.07010000.000001fc0bc...
x86_freebsd   1.3933cb3f.08.20010000.000001fc0bc...
linux         1.3933cb3f.08.49010000.000001fc0bc...

Directory of Legion 1.8 Manuals
[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

Free JavaScripts provided by The JavaScript Source