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

Push task directly to the local queue #62

Open
notgull opened this issue Oct 17, 2023 · 1 comment · Fixed by #93
Open

Push task directly to the local queue #62

notgull opened this issue Oct 17, 2023 · 1 comment · Fixed by #93

Comments

@notgull
Copy link
Member

notgull commented Oct 17, 2023

This was originally implemented in #37, but the implementation turned out to be very buggy so I removed it in #61. Still, I think it's an important optimization even for a reference executor, as it nearly doubles our performance in micro-benchmarks.

// TODO: If possible, push into the current local queue and notify the ticker.

notgull added a commit that referenced this issue Feb 22, 2024
Currently, runner local queues rely on a RwLock<Vec<Arc<ConcurrentQueue>>>> to store the queues instead of using actual thread-local storage.

This adds thread_local as a dependency, but this should allow the executor to work steal without needing to hold a lock, as well as allow tasks to schedule onto the local queue directly, where possible, instead of always relying on the global injector queue.

Fixes #62

Co-authored-by: John Nunley <[email protected]>
@james7132
Copy link
Contributor

james7132 commented Apr 16, 2024

This might need to be reopened due to the revert in 1.10.

The main issue stems from tick-only use cases being unable to find tasks. For which there are some potential options for resolving that problem:

  • Let tick steal tasks if it doesn't find any in the global queue. This might drive higher contention when ticking in a loop from multiple threads.
  • Avoid pushing onto local queues while others are not listening to them.
  • Split tick-able and run-able executors to isolate one use case from another. The former would strictly rely on the global queue, while the latter can be assured that tasks can be stolen if enqueued locally. This will likely require splitting the type or runtime checks, both of which would be breaking changes.

Given that try_tick might be removable in the breaking change, the last option there may be the best for performance across all other options.

@james7132 james7132 reopened this Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants