---
title: Lack of Synchronization (Process Model Behavioural Anomaly)
type: concept
tags: [bpm, modelling, soundness, anomaly, behavioural-correctness, gateways, verification]
sources:
  - "[[sources/2018-dumas-fundamentals-of-bpm]]"
  - "[[sources/2018-dumas-fundamentals-of-bpm-ch5-discovery]]"
  - "[[sources/1998-vanderaalst-verification-of-workflow-nets]]"
created: 2026-05-04
updated: 2026-05-04
---

# 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 ──┘
```

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

- **Petri-net analysis** ([[sources/1998-vanderaalst-verification-of-workflow-nets]]): the extended net (PN-bar) is unbounded → lack-of-synchronisation present. Theorem 11 reduces detection to standard boundedness analysis.
- **Token simulation**: simulate, observe whether more than one token reaches any sequence flow simultaneously.
- **By inspection**: every AND-split must have a matching AND-join; every parallel branch's tokens must be re-merged at the same level.

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

## Related
[[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]]