Lack of Synchronization

A behavioural anomaly in which two or more tokens end up on the same sequence flow because they were not properly synchronised at a join gateway.

Definition (sources/2018-dumas-fundamentals-of-bpm §5.4.1):

Lack of synchronisation occurs when two or more tokens are in the same sequence flow because they were not synchronised at some join gateway.

The classic textbook signal is that the post-join part of the model executes multiple times when it should execute once, or that the end event receives more tokens than expected at completion.

How lack-of-synchronization arises in BPMN

The dominant cause is AND-split → XOR-merge (or XOR-merge after parallelism):

      ┌──▶ B ──┐
A ─◇+─┤        ├──◇X──▶ C ──▶ ◎  ← C executes twice; ◎ receives two tokens
      └──▶ D ──┘
      ┌──▶ B ──┐
A ─◇+─┤        ├──◇X──▶ C ──▶ ◎  ← C executes twice; ◎ receives two tokens
      └──▶ D ──┘

The AND-split releases two tokens (one to B, one to D). The XOR-merge is a passthrough: it forwards each arriving token to its output. So C executes once when B's token arrives, then again when D's token arrives. Both tokens then reach the end event.

Other common causes

Pattern	Why
AND-split → no join → multiple end events on same flow	Same as above without explicit join
OR-split (multiple branches active) → XOR-merge	XOR-merge fires for each active branch
Inclusive merge needed but XOR used	OR-join would have synchronised active branches; XOR doesn't
Branch injected into XOR-block from outside	Extra token arrives without the matching one being routed away

A model with lack-of-synchronization violates proper completion (concepts/soundness clause 2) — the final marking has more tokens than allowed.

Distinction from deadlock

concepts/deadlock is the dual of lack-of-synchronization:

Pattern	Symptom
AND-split + XOR-merge	Lack of synchronisation (XOR fires twice, extra token reaches end)
XOR-split + AND-merge	Deadlock (AND waits for second token that never comes)

Both are mismatched split-join types; one over-fires, the other under-fires.

Detection

Prevention

Block-structuring: only nest blocks of matching split-join type. See concepts/block-structure.
7PMG G4 ("model as structured as possible") prevents most lack-of-synchronisation by enforcing matched gateway pairs.
Tool support: many BPMN tools warn on AND-split/XOR-merge combinations.

Example (Dumas Fig 5.13a)

A model with three activities {C, D, E} where the structure is XOR-merge collapsing what should have been parallel branches. The last sequence flow always carries two tokens (C and either D or E both fire). In some instances activity D may even be executed twice.

Why it matters beyond verification

Lack-of-synchronisation often masks a modelling intent problem: the analyst meant for the post-merge work to happen once, but encoded it in a way that produces multiple executions. Validation with domain experts via translation to natural language usually catches the intent mismatch before the formal anomaly is detected — but the formal check is a backstop.

concepts/soundness · concepts/deadlock (dual) · concepts/livelock · concepts/dead-activity · concepts/block-structure · concepts/workflow-net · concepts/7pmg · frameworks/bpmn

Sources

sources/2018-dumas-fundamentals-of-bpm §5.4.1 · sources/2018-dumas-fundamentals-of-bpm-ch5-discovery · sources/1998-vanderaalst-verification-of-workflow-nets