Process Initiation

To this point, the term "process ID" has been tossed around somewhat haphazardly. This section defines it much more carefully, and describes how it comes to be and what can be done with it. In general, CDS takes a very dynamic approach to program initiation, to accomodate dynamic environments such as computational grids, though it also allows many processes to be initiated simultaneously (which some systems may implement significantly more efficiently). The logical model is defined carefully to allow operating environments where all processes must start executing at "the beginning" (e.g. when the computational resources are allocated) and those where processes can begin execution at later points.

Logical Model

A CDS process joins a CDS program by virtue of being enlisted into it, by a process which already belongs to the program, or by a special "enlist" program if it is the first process in the CDS program. The logical model does not specify what state a process is in before it is enlisted--it may be executing or not. However, a process cannot execute any CDS operations until it performs the cds_init operation, and the cds_init operation will not execute (i.e. will block) until the process has been enlisted.

As part of the execution of the cds_init operation, a process is:

endowed with a 1K-byte comm heap and a single cell context, called the root context, containing one cell, capable of holding up to 10 regions
informed of the process ID of the process which enlisted it (or 0 if was enlisted by the "enlist" program, and therefore is the first process in the program)
provided with a process number, which is designated by its enlistor
optionally provided with a region by the enlistor, which is enq'd into the new process's single cell (before completion of cds_init)

As part of cds_init, the new process is also able to specify a list of optional CDS features which it expects to be present in this implementation, and cds_init will respond with the subset of those features which are, in fact, present. This gives the new process the opportunity to accomodate missing features, e.g. by giving up immediately or by arming work-around logic.

As will be discussed shortly, no process (including the enlistor) is provided with a process ID for the new process. As a result, the new process is initially completely anonymous and therefore its cell(s) cannot be targeted by other processes, but the new process can target cells in other processes--specifically, those within its enlistor, or within other processes if their process IDs were included within the region that was placed within the new process's single cell .

This period of anonymity for the new process (before informing the world of its presence) allows it to set itself up properly. First, it can add one or more new contexts which other processes will expect to be present, using the cds_mkcntxt operation discussed in a later section. This will also serve to enlarge the comm heap. Next, it can assign handlers to cells, as it sees fit. Only when these have been performed will it normally enq a region containing its process ID into a cell in one or more other processes which it knows about (e.g. its enlistor), allowing the rest of the program to begin integrating it with the rest of the computation. This region, indicating the identity of the new process to others, is sometimes known as a "birth cry" or "I AM HERE" message.

Now, switching to the perspective of the enlistor, new processes are added to the program using the cds_enlist operation. This operation allows the enlistor to specify a computational resource (e.g. one or more processors), a specification of one or more not-yet-initiated or already-initiated (but not-yet-enlisted) processes, a process number (to be provided to one of the new processes and incremented as necessary to provide a unique sequential number to each), and an optional region to be "broadcast" to each process (as if with an enqm operation). cds_enlist is a non-blocking operation: it does not (necessarily) wait for specified processes to start up, nor does it return any sort of value to indicate whether or not the processes started up correctly (though standard argument checking is performed). This theoretically allows the enlistor to proceed to enlist other processes even before the previous ones have completely been "born". It is therefore up to the program (often in the enlistor) to wait for and count the appropriate number of birth cries to know that an enlist operation has succeeded. (This often motivates writing the program in a manner that assumes that all has gone right until it is determined that something has gone wrong.)

Process IDs are handles, and therefore are similar, in many ways, to Unix FILEs. Each is a small integer (which is typically an index into an internal table containing more specific information). Also like UNIX files, two process IDs having the same numerical value but being held in two separate processes may not both represent the same process. Partially for this reason, when these IDs must be moved from one process to the next, communicating the numeric value is not sufficient, so there is a special CDS data type for process IDs (CDS_PID), which can be used just as any other type in the CDS copy operations. These convert between the numeric form of the process ID (when not in the comm heap) to a much longer and more descriptive form (in the comm heap). The programmer is advised to use cds_typlen (e.g. cds_typlen(CDS_PID,0,0) ) to determine how much room a process ID will actually take when copied to a region.

Another CDS operation which is sometimes useful in this context is cds_myinfo, which supplies all of the same return values as cds_init, but without the side-effect of initiating the CDS characteristics of the processor. In other words, it provides an alternate means to determine the enlistor, the process number, and the optional features implemented in this version of CDS.

Syntax

cds_enlist()
cds_init()
cds_myinfo()
[Arguments to be specified soon]

Physical Model

Non-blocking process creation is meant to permit the asynchronous creation of processes, but it is understood that many systems will not permit this for one reason or another.

[Index] On to Cell Contexts