2.4.3 Resource availability

When users issue a system call, it is targeted to a particular system object. The system call is processed in the local node only when that object is local. In any other case we forward the system call to a remote node by raising a FWD exception to the user.

Assuming the target system object is local, so that the system call proceeds, it is not guaranteed that every resource needed by that system call be present in the local node.

To deal with remote resources, every resource container (CompResources^2.11) implements a make_available method so that whenever a resource is needed it could be fetched to the local node (if that is really required).

Besides, when the container being considered is an AbsCompResource (a container of abstract resources), we have to take into account that resources contained inside it (abstract resources) are able to move around. Thus, in this case we will employ a relocation table to cache known object locations.

In every CompResource, make_available proceeds as follows:

1.

Using the resource identifier, it tries to locate the resource in the allocator used by the AbsCompResource (using the slot field of the resource identifier). If the resource is found there, then there is nothing more to do. When talking about HWCompResources, we use the off_id_t contained in the off_eu_id_t instead (i.e. an off_id_t with the offset field zeroed).

2.

If the resource was not present in the allocator, the relocation table has to be consulted to find out if we know of any object relocation. If we find an entry, we now know where the object is and we are done.

3.

If we don't know where the object is at this point, we assume it is located in its creation node (known by looking in the resource identifier). Thus, we suspect where the object is and raise a MISSING exception providing the expected location to the user so that he could fetch the remote resource and bring it to the local container.

(a)

If the object was indeed at its expected location (it did not move around) the system call is able to proceed as soon as the MISSING exception handler completes successfully. Should the handler fail, the system call is aborted and an ILL (illegal instruction) exception is raised to the Shuttle domain.

(b)

If the object was not at its expected location we will notice it as soon as the user is notified by the remote resource container (where we expected to find the resource). In this case, a location algorithm will be run by the user. The resulting location should be inserted in the container relocation table, if any.

We should note that resource ``relocation'' counts mostly for portals, shuttles and DTLBs. Elementary resource units are not able to move around, so they will always be at their creation nodes.

Besides, because the system can be heterogeneous, a remote resource brought to the local node may be meaningless to us or require some sort of marshaling (eg. when it corresponds to a different architecture). In this case, an XDT exception is raised in order to request to a trusted user translator an image of the remote object in the native format.

We must take into account frozen resources in make_available. As we will say in section  that any attempt to operate on a frozen resource causes a FROZEN exception to be raised, but for melt operations. Thus, whenever the kernel calls make_available this function must consider the resource as ``absent'' from its container it the resource is frozen. The implementation of melt should then avoid make_available to locate the resource to be melted.