The Queue block is used for transient storage of entities. Three types of queueing policies are available for a Queue block: FIFO, LIFO, and Priority.

When a request to send (or push) an entity arrives at a Queue block, the Queue block determines whether it has room to store the entity. If its buffer is full, the Queue block rejects the request to have the entity sent to it. If space is available in its buffer, the Queue block responds that it can accept the entity.

When an entity arrives at a Queue block that uses a FIFO or LIFO queueing policy, the entity is stored at the appropriate end of the buffer. For Queue blocks that use a Priority policy, the Queue block extracts the priority value from an attribute defined for the entity and uses that value to determine where to place the entity in the buffer. The Queue block then sequentially notifies each block connected to its OutEntity port to ask whether it is ready to receive an entity. The Queue block selects an entity (based on the queueing policy—FIFO, LIFO, or Priority) to send out through the OutEntity port to the first downstream block that responds affirmatively. (Entities can also be pulled out through the Queue block’s OutEntity port by a downstream block. In this case the Queue block also selects the entity to release according to the queueing policy.)

When a Queue block’s buffer is no longer full (due to an entity leaving the Queue block or the Queue block’s capacity being increased), the Queue block attempts to pull entities from upstream through the InEntity port until it is at capacity or no entities are available to pull.

If the Queue block’s reneging option is activated (by selecting the Reneging option in the properties dialog box), then after an entity enters the Queue block, the Queue block attempts to pull a numeric value from its InRenegeWait port. If the Queue block pulls a nonnegative number from the port, it schedules a time for the entity to exit the Queue block via the OutRenege port if the entity is still in the Queue block’s buffer at that time. Otherwise no time for reneging is scheduled. If there is no connection to the OutRenege port, no reneging occurs.

Any time an entity enters or exits the Queue block, the Queue block pushes the value of its buffer’s length (the number of entities being held by the Queue block) to the OutLength port. Any time an entity exits the Queue block via its OutEntity port, the Queue block pushes a value that represents how long that entity waited in the buffer to the OutWait port.

An integer value can be pushed through the InCapacity port to set the capacity for the Queue block (the size of its buffer). Valid incoming values for this port are integers in the range of 0 to 2,147,483,647. If the capacity of a Queue block is reduced dynamically during the simulation run, any excess entities are removed from the Queue block (according to the queueing policy being used) and are sent out the OutBalk port. If there are no connections to the OutBalk port, the entities are destroyed.

Entities in Simulation Studio are hierarchical. That is, entities can hold other entities. The term controlling entity denotes an entity that holds other entities, and the term root entity denotes an entity that is not held by another entity. Each entity held by another entity has one root entity associated with it. The root entity for any held entity is found by traversing up the entity hierarchy from the held entity.

Entities being held by a Queue block can be preempted either by input to the block’s InPreempt port or by a scheduled resource entity event. In order for a root entity that is held by a Queue block to be preempted, the OutPreempt port (or OutBalk port) must have at least one link attached to it. Similarly, for a resource entity that is held by a controlling entity that is in turn held by the Queue block to be preempted, the OutResource port (or OutBalk port) must have at least one link connected to it.

The Queue block’s InPreempt port accepts an Entity Group object as input. (An Entity Group is a collection of references to entities.) When an Entity Group object is pushed to a Queue block’s InPreempt port, the Queue block iterates through the Entity Group collection looking for matches to root entities held by the Queue block. For any matched entity, the Queue block first tries to push that entity out its OutPreempt port. If this push is not successful, the block attempts to push the entity out the OutBalk port. If this also fails, the entity continues to be held by the Queue block until either it exits out the OutEntity port or it is preempted again.

The Queue block, like all entity holding blocks, detects potential preemptive changes (such as those scheduled by a Resource Scheduler block) to resource entities it holds (either directly or indirectly through a controlling entity).

If the number of units associated with a held resource entity decreases or the state of a held resource entity becomes nonfunctional, the Queue block attempts to preempt that resource entity. If the resource entity identified for preemption is a root entity, then the Queue block follows the same protocol for pushing an entity out its OutPreempt port that the InPreempt port uses. If the resource entity is part of a controlling entity, the Queue block removes the resource entity from the controlling entity and attempts to push the associated root entity out the OutPreempt port. The Queue block then attempts to push the preempted resource entity out its OutResource port, or if that fails, out its OutBalk port. If there is a connection to the Queue block’s OutResource port and the Queue block cannot push the resource entity out either the OutResource or OutBalk port, the resource entity is disposed.

The Queue block also provides an OutHoldings port that other blocks can use to pull an Entity Group object that contains a collection of references to entities held by the Queue block.