Handlers, Active Msgs

For some programs, it is more natural to program in a data driven approach where the program responds to the presence of communicated data (or to the demand for data). While full functionality is difficult to deliver on all architectures, CDS provides a minimal and portable set of functionality.

Logical Model

Using the cds_hdlr operation, the programmer can endow any cell with a high- or low-water mark, a function (sometimes called a "handler"), and a CDS-specific priority at which the handler is to execute. The main program also has a CDS-specific priority (of 10 by default). Any handler or main program can change its CDS priority using the cds_setpri function.

The intent of setting these attributes is for the handler to be executed when the number of regions in the cell meets or surpasses the mark. Specifically, a handler is made eligible to execute whenever the number of regions in a cell is less than or equal to the low-water mark before a cds_deq or cds_read operation to the cell is performed, or the number of regions is greater than or equal to the high-water mark after a cds_enq or cds_write operation to the cell is performed. An eligible handler will be initiated (i.e. will begin execution) if and only if

The process which registered the handler (i.e. the one that owns the comm cell with which the handler is associated) enters the CDS system (i.e. by calling a CDS primitive) and
The new handler has a CDS priority at least as great as the handler (or mainline) which executed that CDS primitive

Previously-initiated handlers will not execute until the new handler is complete, even if the new handler lowers its CDS priority to less than that of the previously-initiated handler. That is, once a handler is initiated, it will execute until it is finished, perhaps pausing while subsequent handlers with greater or equal CDS priority initiate and complete.

Note that the low-water mark on a comm cell may be zero, denoting that the handler is made eligible when an cds_deq or cds_read is performed on an empty cell. This allows a "fresh" region to be created on-the-fly, as it is requested, rather than storing a "stale" region in a cell and waiting for processes to pick it up. For incoming regions, a similar strategy can be performed by initiating a cds_ideq operation on the cell, and then setting a high-water mark of 1 with a handler that waits for the completion of that operation. In other cases, the low- and high-water marks can be used to initiate special flow control when comm cells become too full or too empty.

If an entire program is to execute in an event-driven (or data-driven) manner, the standard approach is for the main program to enq any initial regions required to get the program going, then to set its priority very low with cds_setpri and block indefinitely attempting to deq an "all done" region from a cell reserved by the programmer for that purpose. Thus, any and all handlers (all with priority greater than the mainline) will execute until one has enq'd the "all done" region and all eligible handlers have finished executing, at which point the mainline will resume. For other cases, the cds_allow operation temporarily lowers the priority of the calling handler (or mainline) to allow all eligible handlers of that priority or higher to be initiated before returning. (cds_allow has exactly the semantics of a cds_setpri to the lower priority, followed immediately by a cds_setpri back to the original priority.)

Handlers can be used to implement asynchronous collective operations.* For example, a broadcast can be implemented by reserving two comm cells in each process as a Broadcast Read and Broadcast Write. Associated with each Broadcast Write cell, a high-priority handler with a high-water-mark of 1 would deq the region from the Write cell and enq it to the Read cell of the same process and to the Write cells of successive processes in the broadcast tree. With these handlers in place, a process can broadcast a region by enqing it into the Write cell of the root of the tree, and processes would receive the broadcast by reading their own Read cells.

*Note: This example is for illustrative purposes only, and is not a recommended programming practice, because "hardwiring" a broadcast tree like this into the program severly jeopardizes architecture independence. The more portable (and usually more efficient) approach would be to use a multi-to-multi operation as described in the next section.

Syntax

cds_hdlr(cntxt, cell, (*handler)(), prior)
cds_prior(prior)
cds_allow(prior)

Physical Model

Handlers are actually implemented as standard subroutines, to ease implementation and increase efficiency. That is, the number of times that the handler for each cell has become eligible (perhaps from an operation performed by a daemon) is kepts in shared memory, and these counts are checked whenever a CDS operation is performed. If the count for a queue is non-zero, the handler subroutine is called the appropriate number of times.

[Index] On to Many-to-Many Operations