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

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