Programming Interface

The API for the cooperative computing model is given in Table 26.1. It provides simple, yet powerful, primitives. SMs can access the tag space, dynamically create new SMs, synchronize on tags, and migrate to nodes of interest.

createTag, deleteTag, readTag, and writeTag. These operations allow SMs to create, delete, or access existing tags. As mentioned in Section 26.3, these operations are subject to access control. The same interface is used to access the I/O tags. SMs can issue commands to I/O devices by writing into I/O tags or can get I/O data by reading I/O tags.

createSMFromFiles, createSM, and spawnSM. An SM is created by injecting a program file at a node; this program calls createSMFromFiles with a list of program file names to build the new SM structure. An SM may use createSM during execution to assemble a new SM from a subset of its code and data bricks. A createSM call is commonly used to create a route discovery SM when routing information is not locally available. An SM that needs to clone itself calls spawnSM; this primitive returns true in the "parent" and false in the "child" SMs. Typically, spawnSM is invoked when the current computation needs to migrate a copy of itself to nodes of interest while continuing the execution at the local node. A newly created SM is inserted into the SM ready queue.

blockSM. This primitive implements the update-based synchronization mechanism. An SM blocks on a tag waiting for a write. To prevent deadlocks, blockSM takes a timeout as parameter. If nobody writes the tag in the timeout interval, the VM returns the control to the SM. A typical example is an SM that blocks on a routing tag while waiting for a route discovery SM to bring a new route.

TABLE 26.1 Cooperative Computing API



Tag space operations createTag(tag_name, lifetime, data); deleteTag(tag_name);

readTag(tag_name); writeTag(tag_name, value); SM creation createSMFromFiles(program_files);

createSM(code_bricks, data_bricks); spawnSM(); blockSM(tag_name, timeout);

migrateSM(tag_names, timeout); sys_migrate(next_hop);

SM synchronization SM migration

1 Typical_SM(tag){

2 do

3 migrateSM(tag, timeout);

4 <do computation>

6 migrateSM(back, timeout);

FIGURE 26.4 Code skeleton for typical smart message.

migrateSM and sys_migrate. The migrateSM primitive implements a high-level content-based migration, provided usually as a library function. It allows applications to name the nodes of interest by tag names and to bound the migration time. When migrateSM returns normally (no timeout), the SM is guaranteed to resume its execution at a node of interest. In case of timeout, the SM regains control at one of the intermediate nodes in the path. Figure 26.4 presents an example of a typical SM that uses migrateSM. For instance, this SM can be used in the object tracking application described in Section 26.2. The SM migrates to nodes hosting the tag of interest and executes on these nodes until a certain quality of result is achieved. When this is done, the SM migrates back to the node that injected it into the network.

The migrateSM function implements routing using routing tags, the low level primitive called sys_migrate, and possibly other SMs for route discovery. An SM can choose among multiple migrateSM functions that correspond to different routing algorithms. The sys_migrate primitive is used to migrate SMs between neighbor nodes. The entire migration protocol of capturing the execution state and sending the SM to the next hop is implemented in sys_migrate.

0 0

Post a comment