Comparing 3 petri-net variants
1. PetriNet
- General Behavior: Petri nets allow the most general and flexible state transitions, supporting multiple states being active at once and various roles or conditions for enabling transitions.
- Fire Method:
petri_net_fire
- Transitions update states based on their
delta
values. - Guards are applied to inhibit transitions if conditions are not met.
- The result includes flags for
overflow
,underflow
, and whether the transition wasinhibited
. - Supports full vector addition for state changes, with capacity checks.
- Transitions update states based on their
- Key Features:
- Most complex and capable model.
- Can handle arbitrary guard conditions and multiple active states.
2. Elementary
- General Behavior: Simplifies the Petri net model, restricting the number of active states post-transition to one. This ensures clear, single-state progression.
- Fire Method:
elementary_fire
- Works similarly to
petri_net_fire
, but includes an additional check to ensure only one state is active (output_state_count == 1
). - Transitions are inhibited if multiple states are active after firing.
- Works similarly to
- Key Features:
- Simplifies state behavior by enforcing single-state transitions.
- Suitable for workflows where transitions must always result in a single active state.
3. Workflow
- General Behavior: A further simplification of the Elementary model, explicitly designed for workflows with retry and reentry behavior. Allows more leniency in retrying failed transitions while enforcing constraints on state updates.
- Fire Method:
workflow_fire
- States are constrained to values
0
,1
, or2
: 0
or-1
: Inactive states or retryable errors.1
: Active state.2
: Overflow; mapped to1
for retry or inhibited transitions.- Enforces single active state but introduces retry behavior.
- Allows transitions with specific conditions (e.g.,
allow_reentry
).
- States are constrained to values
- Key Features:
- Designed for task flows or processes with explicit reentry behavior.
- Introduces stricter constraints but enables retry loops for overflow states.
Comparison
Practical Applications:
PetriNet: Use for complex, concurrent systems where multiple states must interact or coexist.
Elementary: Apply to simpler decision trees or systems that require deterministic, single-state outputs.
Workflow: Ideal for workflows or task management systems where retry and fail-safe mechanisms are essential.
This framework allows flexible modeling based on system requirements, enabling efficient and accurate representation of different operational paradigms.
Review the Rust code on used to compare these algorithms on github.