GitLab

Context: Several worker_threads are woken up. Meanwhile progress is made
and the desired number of workers is reduced.
Problem: the first worker to wakeup will go back to sleep, even if
it could pick up work. This effectively increase latency before work
is picked up.
Expected: a worker that was just woken up should pick up pending work.

Fix: Avoid using GetDesiredNumAwakeWorkersLockRequired() to make
a decision of going back to sleep. |max_tasks_| is used instead.
If a worker is active and sees available work, it should *always* pick
it up, unless prevented by |max_tasks_|.

Drive by: call CanGetWorkLockRequired for early exit. There's no
point attempting to wake up additional workers if the current worker
was going back to sleep.


Change-Id: I7c7243046372ec99444320256f2df8d32e0d07a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2568903
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#834258}