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

Investigate overflown controlState in CoroutineScheduler #3642

Closed
qwwdfsad opened this issue Feb 25, 2023 · 0 comments
Closed

Investigate overflown controlState in CoroutineScheduler #3642

qwwdfsad opened this issue Feb 25, 2023 · 0 comments
Assignees
@qwwdfsad
Labels
bug

Comments

@qwwdfsad
Copy link
Collaborator

qwwdfsad commented Feb 25, 2023 •
edited
Loading

During my work on #3641 and debugging internal-API specific tests, I've stumbled across the scenario (currently reproducible only with CoroutineSchedulerInternalApiStressTest with last lines uncommented) where controlState overflows and interfere with CPU tokens control mechanism.

The bug seemed to be here nearly since the very beginning and should be assessed and investigated without the use of IDEA-only internal API. The potential impact is unclear
@qwwdfsad qwwdfsad added the bug label Feb 25, 2023
@qwwdfsad qwwdfsad self-assigned this Feb 25, 2023
@qwwdfsad qwwdfsad mentioned this issue Mar 20, 2023
Merged
qwwdfsad added a commit that referenced this issue Mar 20, 2023
@qwwdfsad
Fix oversubscription in Dispatchers.Default
2efea77 
Previously, an arbitrary task was added to the scheduler's queue and the corresponding counter was incremented. The actual executing thread decremented the counter as soon as the task was done, meaning that, if timings are unlucky enough, the overall balance of blocking tasks could've been negative.

The second part of the equation is that all increments are atomic (instead of being CAS-based), meaning that due to programmatic bugs like the previous one, it's easy to overstep the boundary of adjacent masks, leaving the state in an inconsistent state.

Fix is trivial -- increment counter before publishing, do not reset it if the scheduler is closed and task wasn't added.

Fixes #3642
woainikk pushed a commit that referenced this issue Apr 4, 2023
@qwwdfsad @woainikk
Fix oversubscription in Dispatchers.Default (#3684)
65fe7d2 
Previously, an arbitrary task was added to the scheduler's queue and the corresponding counter was incremented. The actual executing thread decremented the counter as soon as the task was done, meaning that, if timings are unlucky enough, the overall balance of blocking tasks could've been negative.

The second part of the equation is that all increments are atomic (instead of being CAS-based), meaning that due to programmatic bugs like the previous one, it's easy to overstep the boundary of adjacent masks, leaving the state in an inconsistent state.

Fix is trivial -- increment counter before publishing, do not reset it if the scheduler is closed and task wasn't added.

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

@qwwdfsad qwwdfsad

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@qwwdfsad