5

In tokio, when the processors finish all the tasks in their run queue, do they first look into the global queue for more tasks or do they try work steal from sibling processors first?

kmdreko
  • 42,554
  • 6
  • 57
  • 106
pandawithcat
  • 571
  • 2
  • 13

1 Answers1

7

Given this is undocumented, I would assume it is unspecified and not part of the library's guarantees unless you can get an issue or PR accepted to specify this behaviour. I would strongly recommend not relying on the current behaviour.

With that being said, "use the code luke" is a short hop away: the main run loop would be Context::run. When the local queue is empty, it calls Core::steal_work which first starts to steal work from a sibling then falls back to the global queue.

Note that schedulers will try to pop tasks from the global queue once in a while during normal operations though, the essay introducing the work-stealing schedulers notes:

The processor will attempt to pop from the global after executing ~60 tasks from the local queue.

Jiří Pospíšil
  • 14,296
  • 2
  • 41
  • 52
Masklinn
  • 34,759
  • 3
  • 38
  • 57
  • right thanks a lot! I'm curious what would be the benefit of stealing tasks against just looking at the global queue? – pandawithcat Oct 17 '20 at 12:28
  • 2
    @LouisLee the global queue is largely for overflow or tasks scheduled from non-scheduler threads, so in normal operations it would likely be empty, especially since checking the global queue is part of normal operations. If every scheduler went for the global queue any time they had no local work, it would also create a lot of contention on that queue. – Masklinn Oct 17 '20 at 12:38