Documentation

Storage

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.

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 as soon as 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.

Distinguishing features of different queues include:

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

  • Discipline — A feature determines which entity departs first if the queue stores multiple entities

Physical Queues and Logical Queues

In some cases, a queue in a model is similar to an analogous aspect of the real-world system being modeled. 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 the 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. Such use of a logical queue can prevent deadlocks or simplify the simulation.

Use the Entity Queue block to model queues.

Queue Policies

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.

Storage Actions

Storage blocks have event actions based on events influencing entities in the corresponding storage blocks. Each block has a set of actions particular to the block.

Entity GeneratorEntity QueueEntity ServerEntity TerminatorResource Acquirer

Entity generation

Entity entry to queue block

Entity entry to server block

Entity entry to terminator block

Entity entry to acquirer block

Entity exit from block

Entity exit from block

Service completion of entity

N/A

Entity exit from acquirer block

N/A

Entity is blocked

Entity exit from block

N/A

N/A

N/A

N/A

Entity is blocked

N/A

N/A

N/A

N/A

Entity is preempted

N/A

N/A

This illustration shows the flow of actions as entities move through a discrete-event system simulation.

Notes:

  • Entity entry, exit, and blocking actions are performed as part of an entity forward event.

  • Service completion action is performed following a timer event.

  • Entity termination event performs a destruction action.

For more information on event actions, see Events and Event Actions.

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 said to be serving the entity that it stores. An everyday example of a server is a person (a bank teller, a retail cashier, etc.) with whom you perform a transaction with a projected duration.

The service time for each entity is computed when it arrives, which contrasts with the inherent unknowability of the storage time for entities in queues. 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.

Distinguishing features of different servers include:

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

  • Characteristics of, or the method of computing, the service times of arriving entities

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

    Tip   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, establishing 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.

What Servers Represent

In some cases, a server in a model is similar to an analogous aspect of the real-world system being modeled. 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

Servers Inserted for Modeling Purposes

In some cases, a server in a model 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

Common server use cases of a server include:

  • In a production line application, the processing unit

  • In a network application, the processor

Constructs Involving Queues and Servers

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

Serial Queue-Server Pairs

Two queue-server pairs connected in series represent successive operations that an entity undergoes. For example, 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

Two queue-server pairs connected in parallel, in which each entity arrives at one or the other, represent alternative operations. For example, 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 preceding this pattern.

Parallel Queue-Server Pairs in Multicasting

Two queue-server pairs connected in parallel, in which a copy of each entity arrives at both, 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

Two queues connected 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 in which 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

Two queues connected in parallel, in which each entity arrives at one or the other, 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.

Entity Resources

Resources are commodities shared by entities in your model. They are independent of entities and attributes, and can exist in the model even if no entity exists or uses them. Resources are different from attributes, which are associated with entities and exist or disappear with their entity.

For example, if you are modeling a restaurant, you can create tables and food as resources for customer entities. Entities can access resources from types of resources. For more information on resources, see Model with Resources.

See Also

| | | | | |

Related Examples

More About

Was this topic helpful?