[dspillett]

But it doesn't have to work that way. The scheduler could scan the whole (unsorted) list at each tick to see if anything is due. No scheduler worth a jot in production is going to do that, but it could.

Saying that sleep sort is really some better form of insertion sort for this reason seems wrong. You might as well say it is bogosort because the scheduler could be using that (and with 1s sleeps it would be faster than sleepsort most of the time despite being generally worse by normal analysis methods).

If a compiler unrolls a short loop to get an extra lick of speed from the tight outer loop, I don't claim I've been clever¹ and spotted the potential optimisation, I probably don't even know it had happened.

--

[1] At a stretch I could claim the opposite: to be clever because I've resisted the urge to over-optimise manually, potentially producing something less performant than a good compiler would on some/all architecture targets while making the code less maintainable too.