Effects of Specifying Event Priorities

Overview of the Example

This example illustrates how selecting or clearing the Resolve simultaneous signal updates according to event priority option—which influences whether or how an event is scheduled on the event calendar—can significantly affect simulation behavior. In particular, the example illustrates how deferring the reaction to a signal update can change how a gate lets entities out of a queue.

In this model (open modelmodel), the Atomic Subsystem block (Compare to 5) returns 1 when the queue length is greater than or equal to 5, and returns 0 otherwise. When the subsystem returns 1, the gate opens to let one or more entities depart from the queue.

The number of entities departing from the queue at a given time depends on the Resolve simultaneous signal updates according to event priority parameter settings in the Enabled Gate block, as explained in the next section.

Default Behavior

By default, the Enabled Gate block at the top level has the Resolve simultaneous signal updates according to event priority option not selected. This block does not have any events with numerical priority values. The simulation behaves as follows:

Simulation Behavior

  1. The queue accumulates entities until it updates the queue length signal, #n, to 5.

  2. The subsystem executes immediately because the execution is not scheduled on the event calendar. The subsystem reports, and the gate detects, that the queue length is at the threshold.

  3. The gate schedules an event to open. The event has priority SYS1.

  4. The application executes the event, and the gate opens.

  5. One entity departs from the queue.

  6. The gate schedules an event to request another entity. The event has priority SYS2.

  7. The queue length decreases.

  8. As a consequence of the queue length's decrease, the subsystem executes immediately because the execution is not scheduled on the event calendar. The subsystem finds that the queue length is beneath the threshold.

  9. The gate schedules an event to close. The event has priority SYS1.

  10. The application executes the gate event. (Note that the application processes events with priority SYS1 before processing events with priority SYS2.) The gate closes.

  11. The application executes the entity request event, but it has no effect because the gate is already closed.

  12. Time advances until the next entity generation, at which point the cycle repeats.

In summary, when the queue length reaches the threshold, the gate permits exactly one entity to advance and then closes. This is because the subsystem reevaluates the threshold condition upon detecting the change in #n, and the gate's closing event has higher priority than its entity request event. The plots of departures from the gates reflect this behavior.

The rest of this example modifies the model to permit the queue to empty completely. The strategies are either to defer the reevaluation of the threshold condition or to defer the gate's reaction to the reevaluated threshold condition.

Defer Gate Events

To illustrate how specifying a numerical event priority for the gate can defer its closing until more entities have advanced, open the original modelmodel and modify it as follows:

Procedure

  1. Open the Enabled Gate block's dialog box by double-clicking the block.

  2. Select Resolve simultaneous signal updates according to event priority.

The change causes the gate to prioritize its events differently. The application processes events with priority SYS1 before processing events with numerical priority values. As a result, the simulation behaves as follows:

Simulation Behavior

  1. The queue accumulates entities until it updates the queue length signal, #n, to 5.

  2. The subsystem executes immediately because the execution is not scheduled on the event calendar. The subsystem finds that the queue length is at the threshold.

  3. The gate schedules an event to open. The event has a numerical priority value.

  4. The application executes the event, and the gate opens.

  5. One entity departs from the queue.

  6. The gate schedules an event to request another entity. The event has priority SYS2.

  7. The queue length decreases.

  8. As a consequence of the queue length's decrease, the subsystem executes immediately because the execution is not scheduled on the event calendar. The subsystem finds that the queue length is beneath the threshold.

  9. The gate schedules an event to close. The event has a numerical priority value.

  10. The application executes the entity request event.

  11. Steps 5 through 10 repeat until the queue is empty. The gate remains open during this period. This repetition shows the difference in simulation behavior between SYS1 and a numerical value as the event priority for the gate event.

  12. The application executes the gate event. The gate closes.

  13. Time advances until the next entity generation, at which point the queue begins accumulating entities again.

In summary, when the queue length reaches the threshold, the gate permits the queue to become empty. This is because the gate does not react to the reevaluated threshold condition until after other simultaneous operations have been processed. The plot of departures from the gates reflect this behavior.

Was this topic helpful?