Open tomtzook opened 3 years ago
@dandeduck this is the thing you wanted
@dandeduck this is the thing you wanted
Yeah, the moment I saw the mail about it I got excited. But I also wonder how well could that even work because of the limited resources, not to mention concurrency issues.
Ran a test with RoboRIO. The implementation proved problematic, with a significant delay in execution and perhaps even a lack of running. Due to a lack of time, it is unclear.
An implementation of
Scheduler
which uses workers executing in a separate thread to run actions.Still requires more testing.
When considering the roboRIO as a platform (which contains an dual-core ARM Cortext-A9), this may not provide much since it only has 2 cores and it is quite likely that there are enough threads (and other processes) executing on the system.
A lot of the implementation depends on cache coherency being maintained across multiple cores. This can be traced to 2 reasons:
ActionContext
orActionState
)According to developer.arm.com
Concept
The idea is pretty straight forward. The scheduler manages several workers, each running in a separate thread, which is a simple daemon.
At any given moment, a worker handles one action, grabbing it from a shared work queue. That action is handled by executing a single cycle (
ActionContext.run
). If the action is finished, it is inserted into a shared finished queue. Otherwise, it is inserted into the shared work queue to be handled again.In order to properly synchronize requirements usage, actually starting and finishing actions is done in the main thread of the robot (which is used to run
Scheduler.run
).Scheduler.run
is used to