Make trex support multi-threaded execution #30
Description
As of now trex reactor execution design is with a single threaded point of view
:
1) synchronize the reactors iteratively from the least dependent to the most dependent
2) select 1 reactor that need to deliberate
3) execute one step of the reactor selected
4) repeat 2-3 until end of tick or no reactor need to deliberate
While t make the design relatively simple it also limits the system as for
example one need to have all the reactor synchronized for the current tick
before being able to deliberate.
A better design would be to look at this in a more asynchronous form. Where :
- a reactor can synchronize as soon as any of the reactor it relies on are synchronized for the given tick
- a reactor can deliberate as soon as it does not need to synchronized (ie it is up to date from the above)
This leads to a more signal based design where a reactor is notified that the
timelines it uses are synchronized up to a given tick asynchronously. When such
signal occur and the min synchronized tick of these external timelines is
greater than the current synchronized tick of this reactor it triggers its
synchronization which when completed will be signaled on all of its internal
timelines.
meanwhile as long as the reactor do not need to synchronize it can od steps of
deliberation until its plan is complete.
Using boost.signals2 and boost.asio the design depicted above could be
implemented in a pure asynchronous view which in turn could allow :
- multi-thread execution of the agent where multiples reactors can be ran in parallel
- it will also allow lower level reactor to synchronize/deliberate without having to wait for upper level reactor to complete their deliberation/synchronization
These two aspects while reducing the pure deterministic execution of trex may
greatly improve the ability of the agent to -- at ;east for lower level
reactors -- be more reactive.
Original issue reported on code.google.com by fre...@gmail.com on 24 Jan 2013 at 11:03