Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/multi threaded scheduling #73

Open
wants to merge 5 commits into
base: development
Choose a base branch
from

Conversation

tomtzook
Copy link
Member

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:

  • state classes used by the scheduler (like ActionContext or ActionState)
  • and state used in implementations of actions by users

According to developer.arm.com

Memory coherency in a Cortex-A9 MPCore processor is maintained following a weakly ordered memory consistency model.
Cache coherency among L1 data caches of the Cortex-A9 processors in the cluster is maintained when the Cortex-A9 processors are operating in Symmetric Multi-Processing (SMP) mode. This mode is controlled by the SMP bit of the Auxiliary Control Register.
To be kept coherent, the memory must be marked as Write-Back, Shareable, Normal memory.

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

  • handle actions in the finished queue (update requirement usage, remove actions and such)
  • place actions into the the work queue
  • start registered default actions if possible

@tomtzook
Copy link
Member Author

@dandeduck this is the thing you wanted

@dandeduck
Copy link
Member

@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.

@tomtzook
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants