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

Can the unified mutex for Inject and Idle in Tokio's Scheduler be safely split? #7233

Open
foreverjun opened this issue Apr 2, 2025 · 0 comments

Comments

@foreverjun
Copy link

foreverjun commented Apr 2, 2025

Hello, I’ve been diving into the Tokio source code to explore potential performance improvements, specifically around the global task queue. I’m considering replacing the inject queue with a lock-free implementation to reduce contention. However, I noticed that inject and idle in the Synced struct are currently protected by a single Mutex:

pub(crate) struct Synced {
    pub(super) idle: idle::Synced,
    pub(crate) inject: inject::Synced,
}

This is defined in worker.rs. I initially assumed this was necessary to ensure state consistency—e.g., to prevent a thread from parking right after a task is added to inject, missing it due to a race. But having looked through the code I haven't found a critical section where something like this can happen.

This change was added in 2023. Before that, inject and idle had separate Mutexes, and the scheduler seemed to work fine. It seems that the “park/unpark” logic hasn't changed significantly since then.
I'd appreciate it if anyone could help me:

  1. Does the unified Mutex for inject and idle provide specific advantages in the current design that I might be missing?
  2. Would separating the global queue (inject) from Synced and making it lock-free be safe, or could it introduce subtle issues (e.g., races between parking and task injection)?
  3. Since the code historically worked with separate Mutexes, is there a reason the single Mutex is preferred now beyond simplicity?
    I’d appreciate any insights or pointers to parts of the code I should double-check. Thanks!
@foreverjun foreverjun changed the title Understanding the rationale behind the unified Mutex for Inject and Idle in Tokio's Scheduler Can the unified mutex for Inject and Idle in Tokio's Scheduler be safely split? Apr 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant