| SimEvents® | |
| On this page… |
|---|
Overview of Notifications and Queries |
In a variety of situations, a SimEvents® block notifies other blocks about changes in its status or queries other blocks about their status. These interactions among blocks occur automatically and are essential to the proper functioning of a discrete-event simulation. Entity request events are one kind of interaction among blocks. Entity request events appear on the event calendar, but other kinds of notifications and queries are not explicitly reported.
Before a SimEvents block outputs an entity, it queries the next block to determine whether that block can accept the entity. For example,
When an entity arrives at an empty FIFO Queue block, the queue queries the next block. If that block can accept an entity, the queue outputs the entity at the head of the queue; otherwise, the queue holds the entity.
While a Single Server block is busy serving, it does not query the next block. Upon completion of the service time, the server queries the next block. If that block can accept an entity, the server outputs the entity that has completed its service; otherwise, the server holds the entity.
When an entity attempts to arrive at a Replicate block, the block queries each of the blocks connected to its entity output ports. If all of them can accept an entity, then the Replicate block copies its arriving entity and outputs the copies; otherwise, the block does not permit the entity to arrive there and the entity must stay in a preceding block.
After a Time-Based Entity Generator block generates a new entity, it queries the next block. If that block can accept an entity, then the generator outputs the new entity; otherwise, the behavior of the Time-Based Entity Generator block depends on the value of its Response when blocked parameter.
When a block (for example, a Single Server block) attempts to advance an entity to the Input Switch block, the server uses a query to check whether it is connected to the currently selected entity input port of the Input Switch block. If so, the Input Switch queries the next block to determine whether it can accept the entity because the Input Switch block cannot hold an entity for a nonzero duration.
When an entity attempts to arrive at an Output Switch block, the block must determine which entity output port is selected for departure and whether the block connected to that port can accept the entity. If the Switching criterion parameter is set to First port that is not blocked, then the Output Switch block might need to query more than one subsequent block to determine whether it can accept the entity. If the Switching criterion parameter of the Output Switch block is set to From attribute, then the block also requires information about the entity that is attempting to arrive.
When a SimEvents block undergoes certain kinds of status changes, it notifies other blocks of the change. This notification might cause the other blocks to change their behavior or status in some way, depending on the circumstances. For example,
After an entity departs from a Single Server block, it schedules an entity request event to notify the preceding block that the server's entity input port has changed from unavailable to available.
After an entity departs from a queue that was full to capacity, the queue schedules an entity request event to notify the preceding block that the queue's entity input port has changed from unavailable to available.
After an entity departs from a switch or Enabled Gate block, it schedules an entity request event to determine whether another entity can advance from a preceding block. This process repeats until no further entity advancement can occur.
When a Path Combiner block receives notification that the next block's entity input port has changed from unavailable to available, the Path Combiner block's entity input ports also become available. The block schedules an entity request event to notify preceding blocks that its entity input ports are available.
This case is subtle because the Path Combiner block usually has more than one block to notify, and the sequence of notifications can be significant. See the block's reference page for more information about the options.
When an entity arrives at a Single Server block that has a t signal input port representing the service time, that port notifies the preceding block of the need for a new service time value. If the preceding block is the Event-Based Random Number block, then it responds by generating a new random number that becomes the service time for the arriving entity.
This behavior occurs because the t signal input port is a notifying port; see Notifying, Monitoring, and Reactive Portsfor details.
| Livelock Prevention | Notifying, Monitoring, and Reactive Ports | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |