Parallelism and Servers

In Stochastic Petri Nets, every timed transition has a server concurrency policy that determines whether it serves one item at a time or multiple items concurrently. This is one of the most critical modeling choices: getting it wrong produces plausible-looking numbers that are mathematically invalid.

---

Single Server vs. Infinite Server

In Jupiter, selecting any timed transition allows you to choose its server policy:

Policy	Letter in editor	Meaning	Behavior
Single Server	S	Serves only 1 item at a time	Even if 10 tokens arrive, the transition processes them strictly one by one sequentially.
Infinite Server	I	Serves as many items as arrive	Imposes no internal bottleneck: if $N$ tokens arrive, all $N$ advance in parallel.

On the canvas, every timed transition displays the letter S or I inside its rectangle, making the concurrency policy visible across the whole model.

"Infinite Server" does not mean unlimited capacity

"Infinite Server" merely means that the transition does not artificially restrict concurrency itself. Real capacity limits are enforced by capacity places. An Infinite Server transition fed by a place with 3 worker tokens will process at most 3 items in parallel.

---

Impact on Performance: The Single Server Trap

Consider an M/M/1 queue with 5-minute service time and arrivals every 10 minutes. Observe what happens when extra workers are added with and without infinite server concurrency:

Workers	Concurrency enabled?	Average queue	Total in system	Mean response time
1	—	0.50	1.00	10.0 min
2	No (Single Server)	0.25	1.00	10.0 min
2	Yes (Infinite Server)	0.03	0.53	5.3 min
4	No (Single Server)	0.06	1.00	10.0 min
4	Yes (Infinite Server)	0.00	0.50	5.0 min

What the numbers reveal

Look closely at the 2 and 4 worker rows under Single Server:

• The waiting queue appears smaller (drops from 0.50 to 0.25).
• However, the total number of items in the system stays locked at 1.00.
• The customer response time stays completely unchanged at 10.0 min.

The Trap

Adding staff or servers without enabling parallel execution (Infinite Server) does not improve response time: it merely shifts where tokens wait. Items leave the queue and enter service; but because the transition only processes one at a time, the extra tokens end up queueing inside the service stage itself.

With the transition set to Infinite Server, both workers process requests simultaneously: total items in the system drop to 0.53 and response time is cut in half (5.3 min).

---

Decision Guide

When to use Single Server (S)

Use when the physical resource is strictly sequential and mutually exclusive:

• A single human cashier.
• A shared physical printer.
• A single mechanical arm or hard drive write head.
• A half-duplex communication channel.

When to use Infinite Server (I)

Use when the stage represents a shared pool or concurrent processing units:

• A team of $N$ attendants (governed by an initial marking of $N$ in a worker place).
• A multi-core CPU or server cluster with $N$ worker threads.
• A delay line or network pipe where multiple packets travel in flight at once.

Golden Rule

If you created a capacity place representing $N$ shared resources (where tokens are acquired upon entry and released on exit), the timed service transition must almost always be configured as Infinite Server. Otherwise, those $N$ resources will never operate concurrently.

---

The "Capacity Without Effect" Warning

Jupiter includes a pre-flight model analyzer that flags this common modeling flaw:

If the engine detects a timed transition set to Single Server drawing tokens from a place that has an initial marking greater than 1 (or can hold multiple tokens simultaneously), it issues a warning:

Capacity without effect: The transition serves one item at a time, but the input resource provides capacity greater than 1.

Whenever this warning appears in your results, change the transition policy to Infinite Server.

Next steps

Learn how to manage constants and model variables in 3 · Parameters.