Concurrency

Process concurrency is expressed using the Fork and Join shapes. As the names suggest, the Fork shape allows control to pass concurrently to multiple outgoing flows, and the Join shape is used to synchronize the resulting outgoing flows. The Join shape also may be used with the Decision shape to synchronize flows following the possible outcomes of a decision (refer to Figure 9.5).

At a Fork, the flow control can split at most 64 ways. The resulting flow can terminate either at an End shape or at a Join. All flows being synchronized at a Join must have emanated from a single Fork—that is, the Fork and Join shapes must be pair matched—except when Join is used with a Decision shape. As with Fork, Join too can synchronize at most 64 flows. Figure 9.6 shows a legal structure of Fork and Join shapes.

Figure 9.6 shows that each Fork shape is paired with a corresponding Join shape. You cannot remove the Join shape marked A just because there is only a single flow coming in. You also cannot remove the shape marked B hoping that the following Join can be used instead to synchronize all the flows.

There are two kinds of Joins: One is OR, and the other is AND. The type of the Join determines the kind of synchronization performed.

For an AND Join, the control does not flow out to the next shape until control reaches the Join from all flows coming in. For an OR Join, the control flows out immediately to the next shape as soon as control reaches it from any of the incoming flows.

The AND Join has fewer restrictions on its use. You can string multiple actions in the process flow leading up to this Join. Because all the concurrent incoming flows are guaranteed to have completed when the flow exits the AND Join, the actions following the Join can assume that the actions along the earlier concurrent pathways have completed—that the results of those actions are not indeterminate. Also, not all paths from a Fork need terminate at the AND Join; some may terminate in the End shape instead. However, none of this is true for the OR Join, which is described next.

For an OR Join, each flow segment reaching up to it can have exactly one receive action. This restriction does not apply if the flow is emanating from a Decision shape. The OR Join is satisfied when any one of the incoming flows completes; therefore, there is no guarantee about the state of other flows coming into the Join. The actions associated with those concurrent flows may or may not have completed. Note, however, that all actions leading up to the Join are attempted and are expected to execute.

Actions along parallel paths of execution (from a Fork) should never attempt to communicate messages. If you attempt this, you may get arbitrary behaviors or runtime failures with no indication of what went wrong—I don't know which option is worse.