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.

Sign up for GitHub

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

Jump to bottom

CoroutineScheduler: do not re-add stolen task to the head of the WorkerQueue where the task can be stolen from again #3416

Closed
qwwdfsad opened this issue Aug 22, 2022 · 0 comments
Closed

CoroutineScheduler: do not re-add stolen task to the head of the WorkerQueue where the task can be stolen from again #3416

qwwdfsad opened this issue Aug 22, 2022 · 0 comments
Assignees
@qwwdfsad
Labels
performance

Comments

@qwwdfsad
Copy link
Contributor

We should hand it directly to the stealing worker without intermediate stores.

Apart from code being more straightforward, it also saves us at least 2 CASes on a fairly contended memory location
qwwdfsad added a commit that referenced this issue Nov 22, 2022
@qwwdfsad
Introduce a separate slot for stealing tasks into in CoroutineScheduler
ed9c9d9 
It solves two problems:

* Stealing into exclusively owned local queue does no longer require and CAS'es or atomic operations where they were previously not needed. It should save a few cycles on the stealing code path
* The overall timing perturbations should be slightly better now: previously it was possible for the stolen task to be immediately got stolen again from the stealer thread because it was actually published to owner's queue, but its submission time was never updated

Fixes #3416
@qwwdfsad qwwdfsad self-assigned this Nov 22, 2022
@qwwdfsad qwwdfsad mentioned this issue Nov 22, 2022
Merged
qwwdfsad added a commit that referenced this issue Nov 22, 2022
@qwwdfsad
Introduce a separate slot for stealing tasks into in CoroutineScheduler
20daaa7 
It solves two problems:

* Stealing into exclusively owned local queue does no longer require and CAS'es or atomic operations where they were previously not needed. It should save a few cycles on the stealing code path
* The overall timing perturbations should be slightly better now: previously it was possible for the stolen task to be immediately got stolen again from the stealer thread because it was actually published to owner's queue, but its submission time was never updated

Fixes #3416
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@qwwdfsad qwwdfsad

Labels
performance
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@qwwdfsad and others