A Simple Discrete-Event Simulation: Part 50

Today I got the new permission logic working. It uses a simpler and more consistent mechanism for determining whether new entities can go into exclusive components and the Path components that feed them. When an entity is ready to be forwarded to the next component it has to check to see if the next component (including the Path components that feed them) is open. It does this by comparing the number of entities in the destination component (and feeding paths) to the maximum capacity of the destination component.

Here’s how the Queue and Process components, each of which can be linked to multiple, incoming Path components, count the number of entities present. Notice that the method also sets the open/closed status for the component, but not the open/closed status for the incoming Path components. This status sets the color of the component when it is drawn. Green and red indicate open and closed, respectively.

Here’s how the Path component does it. Note that this method is recursive to count the entities in multiple Path components linked in series. It has the side-effect of setting the open/closed status for each Path and destination component.

The isOpen calls are made whenever an entity is testing to see whether it can enter a component, when it enters a component, and in some cases when it leaves a component. If an entity entering a Path or destination component and brought the system up to its capacity you can imagine that it might have a problem moving between components in the system. I therefore found it necessary to add a permissionToMove flag in the entity object. This is set to true whenever an entity is received by an exclusive Path component and set to false whenever an entity is received by a non-Path component (that also isn’t an Entry or Exit component).

When an entity leaves a non-Path component it checks to see if leaves the component in an open status (which it should always do). If so, it reaches back to all the incoming paths to set their statuses to open as well. Here’s the forwardEntity code for the Queue and Process components.

Here’s the setPreviousOpen method from the Path component.

It occurs to me that the entire isOpen mechanism doesn’t need to be invoked when an external entity wants to test to see if it can enter. It may be that, since the openStatus of each component should be properly set based on events, we can simplify things by testing against that status directly.

This entry was posted in Simulation and tagged . Bookmark the permalink.

Leave a Reply