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:
OUTPORT (OUTPORT (real)) po ! Interface portOUTPORT (real) qo ! Other port
SEND(po) qo ! Send qo on po; invalidates qo
SEND(qo) x ! Try to send on qo; error!
INPORT (real) p1, p2 ! p1 and p2 are inports, type realMOVEPORT(from=p1, to=p2) ! Set p2 to p1; invalidate p1
© Copyright 1995 by Ian Foster