[DBPP] previous next up contents index [Search]
Next: 6.7 Argument Passing Up: 6 Fortran M Previous: 6.5 Asynchronous Communication

6.6 Determinism

 

An important property of FM is that programs that do not use the nondeterministic constructs MERGER or PROBE can be   guaranteed to be deterministic even if tasks and channels are created   and deleted and channels are reconnected dynamically. The compiler and/or runtime system signal nondeterministic execution of programs that do not use nondeterministic constructs. As noted in Section 1.3.1, determinism can greatly simplify program development.

Individual FM processes execute deterministically. In addition, FM's send and receive operations maintain determinism as long as each channel has at most a single writer and a single reader. Hence, nondeterminism can arise only if an inport or outport is duplicated. This duplication would allow two or more processes to read or write   the same channel, in which case the value retrieved from a channel with a receive operation would depend on the order in which different send and receive operations were executed. Situations in which this undesirable behavior could occur, and the FM mechanisms that avoid it, are as follows:

  1. A port occurs more than once in a process block or process do-loop. The compiler and/or runtime system detects this and signals an error.

  2. A port is communicated in a message and then used locally. The compiler generates code to invalidate a port that has been communicated. Hence, in the following code fragment the second send statement is erroneous and would be flagged as such either at compile time or at runtime.

     
    		 OUTPORT (OUTPORT (real)) po 		 ! Interface port
    

    OUTPORT (real) qo ! Other port

    SEND(po) qo ! Send qo on po; invalidates qo

    SEND(qo) x ! Try to send on qo; error!

  3. A port occurs in an assignment statement. This situation is detected and flagged as an error by the compiler. The value of a port variable can be assigned to another port variable by using   the MOVEPORT statement, but in this case the source port variable is invalidated. For example, the following code both sets p2 to the value of p1 and invalidates p1 by setting it to NULL.

     
    		 INPORT (real) p1, p2 		  !  p1 and  p2 are inports,
    type real
    

    MOVEPORT(from=p1, to=p2) ! Set p2 to p1; invalidate p1



[DBPP] previous next up contents index [Search]
Next: 6.7 Argument Passing Up: 6 Fortran M Previous: 6.5 Asynchronous Communication

© Copyright 1995 by Ian Foster