Pattern 3 (Synchronization)

FLASH animation of Synchronization pattern


The convergence of two or more branches into a single subsequent branch such that the thread of control is passed to the subsequent branch when all input branches have been enabled.


AND-join, rendezvous, synchronizer.


The despatch-goods task runs immediately after both the check-invoice and produce-invoice tasks are completed.

Cash-drawer reconciliation can only occur when the store has been closed and the credit card summary has been printed.


Synchronization provides a means of reconverging the execution threads of two or more parallel branches. In general, these branches are created using the Parallel Split (AND-split) construct earlier in the process model. The thread of control is passed to the task immediately following the synchronizer once all of the incoming branches have completed.


The behaviour of the Synchronization pattern is illustrated by the CP-net model in Figure 3. The pattern contains an implicit AND-join, known as the synchronizer, which is considered to be activated once it receives input on one of the incoming branches (i.e. at places p1 or p2). Similarly it is considered to be reset (and hence can be re-enabled) once input has been received on each incoming branch and the synchronizer has fired, removing these tokens.

Figure 3: Synchronization pattern


This pattern has the following context condition: once the synchronizer 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. In other words, all input places to the synchronizer (e.g. p1 and p2) are safe.


Similar to the Parallel Split pattern, the synchronizer can either be represented explicitly or implicitly in a process model. Staffware has an explicit AND-join construct as does SAP Workflow, EPCs, BPMN, and XPDL. Other offerings - WebSphere MQ, FLOWer, COSA, iPlanet and BPEL - represent this pattern implicitly through multiple incoming (and unconditional) control edges to a task. Only when each of these arcs has received the thread of control can the task be enabled. UML 2.0 ADs allow it to be represented in both ways.


The use of the Synchronization pattern can potentially give rise to a deadlock in the situation where one of the incoming branches fails to deliver a thread of control to the join construct. This could be a consequence of a design error or that one of the tasks in the branch failing to complete successfully (e.g. as a consequence of it experiencing some form of exception) or because the thread of control is passed outside of the branch.


None of the offerings examined provide support for resolving this issue where the problem is caused by task failure in one of the incoming branches. Where this pattern is used in a structured context, the second possible cause of deadlock generally does not arise.

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 assumption.

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.





Staffware 10 + Supported through the wait step construct. Note that the wait step has one preceding step (solid line) and possibly multiple steps it is waiting for (dashed lines). The difference between the preceding step and the steps it is waiting for becomes only visible in a loop situation. In a loop the wait step only waits for the preceding step (solid line) and no longer has to wait for the other steps. The only way to get a "normal" synchronization is a loop is to explicitly reset the step in a loop using the "SETSETSTATUS" function.
Websphere MQ 3.4 + Supported by specifying start conditions on an activity.
FLOWer 3.51 + Nodes in static, dynamic and sequential subplans have an AND-join semantics.
COSA 5.1 + Supported by multiple incoming arcs to an activity. None of the arcs have transition conditions specified.
iPlanet 3.0 + Supported by specifying a trigger condition for an activity with multiple incoming routers that only fires when all routers are activated.
SAP Workflow 4.6c + Directly supported via the fork construct. However, there has to be a one-to-one correspondence between split and join.
FileNet 3.5 + Directly supported by a component the incoming routing info of which is set to "collector step".
BPEL 1.1 + Supported by <flow> construct.
Websphere Integration Developer 6.0 + Supported by the <flow> activity.
Oracle BPEL 10.1.2 + Supported by the <flow> construct.
BPMN 1.0 + Supported by AND-join gateway.
XPDL 2.0 + Supported by the AND-join construct.
UML ADs 2.0 + Supported by the JoinNode construct. It can also be implicitly represented.
EPC (implemented by ARIS toolset 6.2) + Supported by the AND-join connector.
jBPM 3.1.4 + jBPM supports synchronization through:
i) the Join Node construct to which threads running in parallel converges
ii) if the tasks to be synchronized are defined within the same Task Node, the node itself will act as synchronizer of its tasks.
OpenWFE 1.7.3 + OpenWFE is a block structured language. The closing tag </concurrence> for a concurrence block implements synchronization.
Enhydra Shark 2 +

Enhydra Shark supports synchronization through
i) an activity node with a transition restriction <Join Type = "AND"> which synchronizes all source activities of incoming transitions (Shark, Wil)
ii) a routing activity node with a transition restriction <Join Type = "AND"> which synchronizes all source activities of incoming transitions.