Modeling critical sections in BPMN

A part of my bachelor “Business Process Modeling” course is related to teaching common control-flow behavior in business processes and process-aware information systems – commonly known as workflow or more specifically control-flow patterns.

The website is a perfect reference source for teaching control-flow patterns whereas I try to represent the patterns in BPMN, a standardized process modeling language, my students get familiar with in the same course.

Critical Section pattern

The Critical Section pattern limits two or more sections (e.g. tasks or sub-processes) of a process from executing concurrently, which may occur in case of resources (e.g. persons, IT resources, peripheral devices, etc.) capable to handle a single request at the same time only. Just imagine the challenge of two persons trying to change the same desktop document simultaneously.

Critical section
A simple “critical section” scenario

Critical sections modeled with BPMN

The website evaluated BPMN as not having a dedicated construct capable of modeling critical sections. However, a similar functionality may be realized with existing BPMN constructs as evident from the following diagram. The presumption in all examples is that critical sections are not entered in the exactly the same time (in  milliseconds), which would result in an exception.

The first example is most simple and realizes a critical section with guards (conditional events), which validate if the conditions for entering a critical section are met.

WP39 - 5
Critical section pattern realized with conditional events

The drawback of this implementation of the pattern is that the logic, which test the conditions is  implicit and rather abstract. This drawback is well addressed in the following example, which realizes the ‘logic’ of the ‘Critical section’ pattern with Gateways and works almost perfect if the critical sections-related information is available to Exclusive Gateways (should be available in a workflow environment).

Critical section pattern, realized with simple Gateways

The drawback is that a token (depicted on the above figure as a circle) remains in a deadlock after all critical sections have been performed. With some additional logic, this can be addressed as follows.

WP39 - 2
Critical section pattern, realized with inclusive Gateways

The above example realizes the ‘Critical section’ pattern with additional Conditional flows, which bypass the problem with the remaining tokens. However the conditions are rather complex (i.e. the underlying workflow environment should have the knowledge if a critical section is waiting for being performed).

The following Critical section pattern example is realized without complex conditions. Instead it uses Even-based sub-processes and Signal events. A precondition is that Signals are persistent (in case of being transient, the diagram would become more complex).

WP39 - 3
Critical section pattern, realized with Event sub-processes and Signals

As evident from the above pattern, critical sections are entered in case of the default paths (timer events) followed after the Event-based Gateways.


Without a dedicated concept, modeling critical sections in BPMN is rather complex.

The presented example demonstrate that it is possible to implement critical sections with BPMN, without a dedicated ‘critical section’ concept. However, the solutions are rather complex, where each of the presented implementations of the pattern has also its own limitations.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s