Pattern 37 (Local Synchronizing Merge)

FLASH animation of Local Synchronizing Merge pattern

Description

The convergence of two or more branches which diverged earlier in the process into a single subsequent branch such that the thread of control is passed to the subsequent branch when each active incoming branch has been enabled. Determination of how many branches require synchronization is made on the basis on information locally available to the merge construct. This may be communicated directly to the merge by the preceding diverging construct or alternatively it can be determined on the basis of local data such as the threads of control arriving at the merge.

Example

N/A.

Motivation

The Local Synchronizing Merge provides a deterministic semantics for the synchronizing merge which does not rely on the process model being structured (as is required for the Structured Synchronizing Merge) but also does not require the use of non-local semantics in evaluating when the merge can fire.

Overview

Figure 55 illustrates one approach to implementing this pattern. It is based on the use of "true" and "false" tokens which are used to indicate whether a branch is enabled or not. After the divergence at transition A, one or both of the outgoing branches may be enabled. The determinant of whether the branch is enabled is that the token passed to the branch contains both the case id as well as a Boolean variable which is "true" if the tasks in the branch are to be executed, "false" otherwise. As the control-flow token is passed down a branch, if it is a "true" token, then each task that receives the thread of control is executed otherwise it is skipped (illustrated by the execution of the bypass task s1..sn associated with each task). The Local Synchronizing Merge, which in this example is illustrated by transition E, can be evaluated when every incoming branch has delivered a token to the input places for the same case.

Figure 55: Local Synchronizing merge pattern

Another possible solution is provided by Rittgen [Rit99]. It involves the direct communication of the number of active branches from the preceding OR-Join(s) divergence to the Local Synchronizing Merge so that it is able to determine when to fire.

Context

There are two context conditions associated with the use of this pattern: (1) once the Local Synchronizing Merge has been activated and has not yet been reset, it is not possible for another signal to be received on the activated branch or for multiple signals to be received on any incoming branch, i.e. all input places to the Local Synchronizing Merge (place p4 and p5) are safe and (2) the Local Synchronizing Merge construct must be able to determine how many incoming branches require synchronisation based on local knowledge available to it during execution.

Implementation

WebSphere MQ, FLOWer, COSA, BPEL and EPCs provide support for this pattern. UML 2.0 ADs seems to provide support although there is some ambiguity over the actual JoinSpec configuration required.

Issues

None identified.

Solutions

N/A.

Evaluation Criteria

Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumptions. If there is any ambiguity as to the manner in which the synchronization condition is specified, then it rates as partial support.

Product Evaluation

To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.