Condition handlers for dataflow procedures

In "A Localized Condition Handling Construct for a Graphical Dataflow Language" (this proceedings), a condition handling mechanism, called a node supervisor, is introduced. That construct is intended only for nodes and is used to provide condition detection and handling at the individual node level. The work described in that paper has been extended to consider additional issues that arise when considering conditions that impact the graph as a whole. If a node supervisor is unable to fully or properly respond to a given condition then that condition is posted to a "higher" level. That higher level, is called a procedure supervisor. A procedure supervisor can provide some of the same functionality as described for node supervisors, including input acceptance testing (IAT), output acceptance testing (OAT) and condition handling (CH). Procedure supervisors differ from node supervisors in several significant ways. In particular: (1) The conditions being posted to the condition handler may be coming from any one of the nodes hence node identification may be required as part of the condition posting process. (2) The procedure condition tokens may arrive in an asynchronous fashion at the dataflow procedure condition handler. (3) Support for a retry of the procedure as a whole requires additional system support in terms of the ability to halt currently executing nodes and to dispose of tokens scattered throughout the graph. (4) Termination of a dataflow procedure may be more difficult to detect than termination of an individual node. As with node supervisors, procedure supervisors can respond to conditions detected and posted by the system support. At the procedure wide level this can include conditions related to the configuration of the graph at lime of termination. For example, a programmer might have expectations that the graph and any initial tokens present return to the "initial state" by the time the procedure has finished executing. The notion of a snapshot that captures the details of a graph at some point during the execution is convenient. Expectations regarding the final state of the graph can be slated in terms of the terminal snapshot and the defining snapshot (i.e. the description of the original graph). Various levels of invariance can be identified in terms of differences between these two (c.g., variant, token invariant and totally invariant). The concept of a snapshot also proves to be a valuable one with respect to a condition handler requesting system support to capture the "current” stale of execution for debugging purposes. One difficulty regarding gathering snapshots during execution is that, due to liming issues, the snapshot may not reflect the true stale at the moment that the request was made. The system support required for procedure supervisors is more extensive than that required for nodes supervisors. This is seen by looking at the need (a) to propagate a HALT to all nodes, (b) to delect procedure termination, (c) to gather snapshot information and (d) to determine if the desired level of invariance has been met by comparing the defining snapshot to the terminal snapshot While the procedure supervisor construct and the required system support have been studied, work still remains in the area of testing such a construct to determine its viability. It is suspected that the cost of such a mechanism may turn out to be justified only in the context of coarse grain dataflow procedures. Permission lo copy without fee alt or part of this material is granted provided that the copie* are not made or distributed for direct com­ mercial advantage, the ACM copyright notice and the title of the publication and it* date appear, and notice I* given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or lo republish, requires a fee and/or specific per­ mission. © 1990 ACM 0-89791-356-6/90/0400/0196 $1.50