It is clear to me that React.NET supports process-based world view and the 'yield' statement of C# is used instead of threads. However, I'm getting lost when trying to follow the interaction of Tasks, Processes, ActivationEvents etc.
Could you provide some general information about how the whole thing works? I know that your code is very well documented. Nevertheless, it'd be nice to know the big picture.
Out of curiosity, have you been influenced by other simulation libraries like SimPy? Maybe you could provide some good references that put some light on your design.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The big picture is really quite simple. Basically, the Simulation maintains an ordered list of ActivationEvents. The ordering is by time and priority of the ActivationEvent. The Simulation pulls an event out of the list and "fires" it. Each ActivationEvent has an associated Task. When an ActivationEvent is fired, it does some setup in preparation to executing its assocated Task, and then runs the Task. If the Task is a Process, the iterator method is called to do some work.
Normally, simulation developers will never need to work directly with ActivationEvent objects. [In future, I may make this class internal, so it wouldn't show up as part of the public API.]
One important concept in React.NET is that of "task chaining" or having one Task run another to perform some work. This is very prevalent when working with Process instances. In effect, the Process iterator method yields Tasks that will perform some work on behalf of the Process. While the worker Task runs, the Process waits. When the worker Task completes, it normally reactivates the Process, which calls the iterator method, which can yield a new worker Task. Of course, because an iterator method is used, the Process can do some of its own work between yield statements.
Hopefully this helps understand the big picture.
>> Out of curiosity, have you been influenced by other simulation libraries like SimPy?
Interestingly enough, when the version of Python that included generators (iterators) was first released, I thought that would make a neat way to implement a simulation package. I was new to Python and thought it would be a good project. After some searching I discovered SimPy and decided to put any thoughts of writing a simulation framework on hold. When .NET 2.0 with iterators came out, my interest was rekindled and I wrote React.NET.
Over the years I've worked with numerous simulation packages including SimPy and I'm sure I've drawn ideas (or things to avoid) from most of them.
— Eric —
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks for posting this big picture explanation. I will see the code again and make sure I understand every detail of it. I'm very interested if finding out if your framework is robust and can be used for large scale simulation in transportation context.
Do you think that the framework as is has enough expressive power to create any discrete event simulation model? If not, what mechanisms are missing?
Based on your experience in the field, could you recommend any book or papers that give practical informations about engineering discrete event simulations software. The most useful document I've found so far was the tutorial associated with DSOL (another open source project). It seems to me that designing a simulation framework is not that easy. Although at first sight it seems like a simple queue based algorithm. For instance, can things like deadlocks occur?
Thanks,
Mirek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are a lot of problem domains where simulation can be applied. React.NET includes many of the common elements used, but depending upon what you're trying to model you may need others. Of course, since this is a open-source, programmatic framework, you can build those that are missing (possibly easier said than done).
As for recommended reading, there are a few links on the React.NET home page (near the bottom). You may also want to check out www.informs.org and www.wintersim.org. The WinterSim site has links to a large archive of past conference papers in a wide variety of fields/interests.
Finally, with regard to deadlocks, yes, they can occur. However, with the way React.NET runs, when a deadlock occurs that effectively results in no Tasks on the event queue, the simulation would stop.
— Eric —
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I debugged through BarberShop and now I almost understand what's going on. The hardest part is to follow the chaining of Tasks.
It seems to me that there are a lot of ActivationEvents queued with relative time 0, so they are executed very soon but have to be pumped through the priority queue. I wonder if this is required. Would it be all right to continue with the task (process) until blocking or time delay operation needs to be performed. For instance, when acquiring a resource (if success, we keep going).
Could you comment on that? I just want to make sure I'm not missing an important point here.
By the way, I've noticed that the Simulation Run method always resets _stopTime so it's hard to set it other than calling StopSimulation. Looks to me like a bug.
Thanks,
Mirek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's one of the things I don't like about using generators/iterators to simulate processes. It can lead to some rather non-intuitive and hard-to-follow runtime behavior. In order to keep everything running using a common design, all potentially blocking behaviors are accomplished using Tasks and they all get put on the event queue in order to run. That's the reason you see a lot of Tasks being activated at the current simulation time. I wanted everything to operate consistently which is why I don't do any "short circuiting" of this behavior.
>> By the way, I've noticed that the Simulation Run method always resets _stopTime so it's hard to set it other than calling StopSimulation. Looks to me like a bug.
It's working as designed. Simulation.Run(Task[]) resets the stop time and then sets the stop time when the simulation actually stopped. You can only stop a running simulation, which means you need to call Simulation.Stop() or Simulation.Stop(long) after the simulation has started running. If you want to schedule a stoppage, you could use the StopSimulation task by invoking the StopSimulation.Stop(Simulation, long) method BEFORE you call either of the Simulation.Run methods.
— Eric —
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
It is clear to me that React.NET supports process-based world view and the 'yield' statement of C# is used instead of threads. However, I'm getting lost when trying to follow the interaction of Tasks, Processes, ActivationEvents etc.
Could you provide some general information about how the whole thing works? I know that your code is very well documented. Nevertheless, it'd be nice to know the big picture.
Out of curiosity, have you been influenced by other simulation libraries like SimPy? Maybe you could provide some good references that put some light on your design.
Thanks!
The big picture is really quite simple. Basically, the Simulation maintains an ordered list of ActivationEvents. The ordering is by time and priority of the ActivationEvent. The Simulation pulls an event out of the list and "fires" it. Each ActivationEvent has an associated Task. When an ActivationEvent is fired, it does some setup in preparation to executing its assocated Task, and then runs the Task. If the Task is a Process, the iterator method is called to do some work.
Normally, simulation developers will never need to work directly with ActivationEvent objects. [In future, I may make this class internal, so it wouldn't show up as part of the public API.]
One important concept in React.NET is that of "task chaining" or having one Task run another to perform some work. This is very prevalent when working with Process instances. In effect, the Process iterator method yields Tasks that will perform some work on behalf of the Process. While the worker Task runs, the Process waits. When the worker Task completes, it normally reactivates the Process, which calls the iterator method, which can yield a new worker Task. Of course, because an iterator method is used, the Process can do some of its own work between yield statements.
Hopefully this helps understand the big picture.
>> Out of curiosity, have you been influenced by other simulation libraries like SimPy?
Interestingly enough, when the version of Python that included generators (iterators) was first released, I thought that would make a neat way to implement a simulation package. I was new to Python and thought it would be a good project. After some searching I discovered SimPy and decided to put any thoughts of writing a simulation framework on hold. When .NET 2.0 with iterators came out, my interest was rekindled and I wrote React.NET.
Over the years I've worked with numerous simulation packages including SimPy and I'm sure I've drawn ideas (or things to avoid) from most of them.
— Eric —
Hi Eric,
Many thanks for posting this big picture explanation. I will see the code again and make sure I understand every detail of it. I'm very interested if finding out if your framework is robust and can be used for large scale simulation in transportation context.
Do you think that the framework as is has enough expressive power to create any discrete event simulation model? If not, what mechanisms are missing?
Based on your experience in the field, could you recommend any book or papers that give practical informations about engineering discrete event simulations software. The most useful document I've found so far was the tutorial associated with DSOL (another open source project). It seems to me that designing a simulation framework is not that easy. Although at first sight it seems like a simple queue based algorithm. For instance, can things like deadlocks occur?
Thanks,
Mirek
Mirek,
There are a lot of problem domains where simulation can be applied. React.NET includes many of the common elements used, but depending upon what you're trying to model you may need others. Of course, since this is a open-source, programmatic framework, you can build those that are missing (possibly easier said than done).
As for recommended reading, there are a few links on the React.NET home page (near the bottom). You may also want to check out www.informs.org and www.wintersim.org. The WinterSim site has links to a large archive of past conference papers in a wide variety of fields/interests.
Finally, with regard to deadlocks, yes, they can occur. However, with the way React.NET runs, when a deadlock occurs that effectively results in no Tasks on the event queue, the simulation would stop.
— Eric —
Hi Eric,
I debugged through BarberShop and now I almost understand what's going on. The hardest part is to follow the chaining of Tasks.
It seems to me that there are a lot of ActivationEvents queued with relative time 0, so they are executed very soon but have to be pumped through the priority queue. I wonder if this is required. Would it be all right to continue with the task (process) until blocking or time delay operation needs to be performed. For instance, when acquiring a resource (if success, we keep going).
Could you comment on that? I just want to make sure I'm not missing an important point here.
By the way, I've noticed that the Simulation Run method always resets _stopTime so it's hard to set it other than calling StopSimulation. Looks to me like a bug.
Thanks,
Mirek
Mirek,
That's one of the things I don't like about using generators/iterators to simulate processes. It can lead to some rather non-intuitive and hard-to-follow runtime behavior. In order to keep everything running using a common design, all potentially blocking behaviors are accomplished using Tasks and they all get put on the event queue in order to run. That's the reason you see a lot of Tasks being activated at the current simulation time. I wanted everything to operate consistently which is why I don't do any "short circuiting" of this behavior.
>> By the way, I've noticed that the Simulation Run method always resets _stopTime so it's hard to set it other than calling StopSimulation. Looks to me like a bug.
It's working as designed. Simulation.Run(Task[]) resets the stop time and then sets the stop time when the simulation actually stopped. You can only stop a running simulation, which means you need to call Simulation.Stop() or Simulation.Stop(long) after the simulation has started running. If you want to schedule a stoppage, you could use the StopSimulation task by invoking the StopSimulation.Stop(Simulation, long) method BEFORE you call either of the Simulation.Run methods.
— Eric —