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

Refactor WorkerThread runloop; avoid pathological starvation of pollers #4247

Open
wants to merge 4 commits into
base: series/3.6.x
Choose a base branch
from

Conversation

armanbilge
Copy link
Member

Fixes #4228.

At a high level, a WorkerThread is always in one of the following three states:

  1. Working (primarily on the local queue).
  2. Looking for work (external or stolen).
  3. Parked.

Previously, (3) was a separate parkLoop(), but (1) and (2) were entangled in the top-level runloop. Now, (2) is refactored into a separate lookForWork() loop. Thus, the top-level runloop is only responsible for tracking "ticks", such that polling runs every 64 ticks.

worker-runloop-fsm

Comment on lines +355 to +361
def lookForWork(): Unit = {
var state = 0
while (!done.get()) {
(state: @switch) match {
case 0 =>
// Check the external queue after a failed dequeue from the local
// queue (due to the local queue being empty).
Copy link
Member Author

@armanbilge armanbilge Jan 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, we could lift case 0 out of the loop. It's always guaranteed to run exactly once, and never again. The loop just transitions between cases 1 and 2.

@armanbilge armanbilge linked an issue Jan 21, 2025 that may be closed by this pull request
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.

External queue can starve timers/pollers
1 participant