Storage with Queues and Servers

Queue and server blocks are storage blocks that hold entities.

  • Queues order entities and sort them according to queue policies.

  • Servers delay entities until certain conditions are met.

Storage blocks can have event actions based on events influencing entities in the corresponding storage blocks. Each block has a set of events that invoke a specific event action. For more information on event actions, see Events and Event Actions.

Behavior and Features of Queues

In a discrete-event simulation, a queue stores entities for a length of time that cannot be determined in advance. The queue attempts to output entities when it can, but its success depends on whether the next block accepts new entities. An everyday example of a queue is when you stand in a line with other people to wait for some type of service to address your needs and you cannot determine in advance how long you must wait.

The distinguishing features of queues include:

  • Capacity — The number of entities the queue can store simultaneously

  • Queue Policy — Which entity departs first, if the queue stores multiple entities

The Entity Queue block uses these queue policies:

  • FIFO — The block processes the entity as first in first out.

  • LIFO — The block processes the entity as last in first out.

  • Priority — The block reads the priority from the Priority Source parameter. This parameter is a particular attribute value that the block stores based on the value of the number.

Physical Queues and Logical Queues

Sometimes, a queue in a model is similar to an aspect of a real-world system. This kind of queue is sometimes called a physical queue. For example, you might use a queue to represent a sequence of:

  • People standing in line

  • Airplanes waiting to access a runway

  • Messages waiting to be sent

  • Parts waiting to be assembled in a factory

  • Computer programs waiting to be executed

In other cases, a queue in a model does not arise in an obvious way from a real-world system, but instead is included for modeling purposes. This kind of queue is sometimes called a logical queue. For example, you might use a queue to provide a temporary storage area for entities that might otherwise have nowhere to go. Using logical queues can prevent deadlocks or simplify the simulation.

Use the Entity Queue block to model queues.

Behavior and Features of Servers

In a discrete-event simulation, a server stores entities for a length of time, called the service time, and then attempts to output the entity. During the service period, the block is serving the entity that it stores. An everyday example of a server is a person (such as a bank teller, or a retail cashier) with whom you perform a transaction with a projected duration.

The service time for each entity is computed when it arrives. If, however, the next block does not accept the arrival of an entity that has completed its service, the server is forced to hold the entity longer.

The distinguishing features of servers include:

  • The number of entities it can serve simultaneously, which could be finite or infinite

  • The characteristics of, or the method of computing, the service times of arriving entities

  • Whether the server permits arriving entities to preempt entities that are already stored in the server


In the absence of preemption, a finite-capacity server does not accept new arrivals when it is already full. You can place a queue before each finite-capacity server to establish a place for entities to stay while they are waiting for the server to accept them. Otherwise, the waiting entities might be stored in various different locations in the model and the situation might be more difficult for you to predict or analyze.

Types of Servers

In some cases, a server in a model is analogous to a real-world system. For example, you might use a server to represent:

  • A person (such as a bank teller) who performs a transaction with each arriving customer

  • A transmitter that processes and sends messages

  • A machine that assembles parts in a factory

  • A computer that executes programs

In some cases, a server does not represent a real-world system. A common modeling technique involves a delay of duration zero(that is, an infinite server whose service time is zero) to provide a place for an entity to reside to manipulate its attributes.

Use the Entity Server block to model queues.

Common server use cases of a server include:

  • Modeling the processing unit in a production line application

  • Representing the processor in a network application

Modeling with Queues and Servers

You can combine Entity Queue and Entity Server blocks to model different situations:

Serial Queue-Server Pairs

Connecting two queue-server pairs in series can represent successive operations on an entity. For example, you can model how the parts on an assembly line are processed sequentially by two machines.

You can alternatively model the situation as a pair of servers without a queue between them. However, the absence of the queue means that if the first server completes service on an entity before the second server is available:

  • The entity must stay in the first server past the end of service.

  • The first server cannot accept a new entity for service until the second server becomes available.

Parallel Queue-Server Pairs as Alternatives

Connecting two queue-server pairs in parallel, in which entities are routed to one or the other queue-server pair, can represent alternative operations. For example, you can model how vehicles wait in line for one of several tollbooths at a toll plaza. In this case, the model must have decision logic, possibly in the form of a switch that precedes this pattern.

Parallel Queue-Server Pairs in Multicasting

Connecting two queue-server pairs in parallel, in which a copy of each entity arrives at both, can represent a multicasting situation, such as sending a message to multiple recipients. Note that copying entities might not make sense in some applications.

Serial Connection of Queues

Connecting two queues in series might be useful if you are using entities to model items that physically experience two distinct sets of conditions while in storage. For example, additional inventory items that overflow one storage area have to stay in another storage area where a less well-regulated temperature affects the items’ long-term quality. Modeling the two storage areas as distinct queue blocks facilitates viewing the average length of time that entities stay in the overflow storage area.

Parallel Connection of Queues

Connecting two queues in parallel, in which each entity arrives at one or the other, can represent alternative paths for waiting. The paths might lead to different operations, such as a line of vehicles waiting for a tollbooth and a line of vehicles waiting on a jammed exit ramp of the freeway. You might model the tollbooth as a server and the traffic jam as a gate.

Broadcast Entities Using Multicast Mode

Multicast mode enables multiple queues to receive entities from one Entity Multicast block. The receiving block for an Entity Multicast blocks is a Multicast Receive Queue block whose Tag parameters have the same value. The Multicast Receive Queue block is essentially the Entity Queue block with the Entity Arrival source parameter set to Multicast.

Using the Entity Multicast block requires no connecting lines. The Tag parameters just need to match.

  1. From the SimEvents® library, drag the Entity Multicast and Multicast Receive Queue blocks.

  2. In both dialog boxes, in the Multicast tag parameters, enter the same text. For example, A.

The software uses these tags to match the broadcaster and broadcastees.

This is example shows entities broadcast to two queues. Notice that the FIFO blocks for both queues have the A tag.

See Also

| | | | | |

Related Examples

More About