How does sleeping a thread work?

Question

When you sleep a thread, what is actually going on?

I see that sleeping a thread "pauses the current thread for a given period of time". But just how does it work?

According to How Thread.sleep() works internally and How does Thread.sleep really work?:

• the sleep duration will be subject to some system-specific granularity
• sleep is blocking
• the thread leaves the CPU and stops its execution
• the thread is not consuming CPU time while sleeping

I just can't quite understand the internal and fundamental mechanics of what this all means.

I understand that there is something called the scheduler that is responsible for switching between threads.

Sources seem to indicate that this varies by OS (or hardware?) and most threads are given 1ms - 60ms or so to perform some actions before the CPU switches to another thread.

But when a thread sleeps (for example, many seconds), how does it resume? I'm guessing a timer is involved somehow, is it the motherboard's clock? Is it related to the CPU clock rate?

And even if a timer is involved, how does the CPU know when it's time to pay attention to the thread again? Wouldn't it have to constantly check in on the thread to see if it's ready? Isn't that effectively polling and therefore kind of is consuming CPU time?

Is sleeping a thread language-specific or is the OS responsible for it or is it a CPU-specific thing?

Would someone please explain this to me with basic explanations of things like the scheduler and what the CPU is doing during all of this?

Answer 1

There is much more involved in running a program than just the code within that program.

Any program that runs in a multi-process OS is under the control of the OS's scheduler, and the scheduler does maintain an explicit table saying what process is running, which ones are waiting to run when CPU cycles are available, and which are not even trying to run (sleeping). The scheduler typically assigns even-sized time slices to processes depending on their priority and their execution history. Ultimately, this loop is driven by hardware interrupts, usually generated by an oscillator on the main board.

Sleeping is always a feature that a programming language can support only because the run-time environment where it will be executed supports it. A normal program cannot suspend itself, it can only tell the scheduler how it would like to be treated - and the scheduler is by no means obliged or even always capable of satisfying that wish. Think of a laptop being closed and going into hibernation; the main board's oscillator keeps pulsing, but since the scheduler isn't running, no process can be running either no matter how high its priority is.

Answer 2

As Doc Brown mentioned in a comment, interrupts are the key, and not just for sleeping.

An interrupt is a hardware signal that the processor should stop what it's doing and run a piece of code. External devices trigger interrupts when they need the processor's attention: for example, when a disk has finished reading data, or a key has been pressed, or a countdown timer on the motherboard has reached zero.

Interrupt-handling code is generally very small and very fast. For example, when the disk indicates a block has been copied to memory, the OS might simply record that fact in a list of "ready blocks" somewhere and then return to whatever else it was doing. You don't want the CPU to be spending all of its time in interrupt-handling code and not running user code.

One piece of interrupt-driven code that isn't necessarily small is the scheduler. It's triggered by a signal from a countdown timer, and examines the state of the system whenever it's run. This will typically include identifying processes that are ready to run (for example, because the block that they were waiting for has arrived in memory), as well as those that have exhausted their time slice.

So, when you execute a thread sleep, what you're doing is telling the OS that (1) you're giving up your time slice, and (2) you shouldn't be awoken again until a certain time has elapsed.

Whenever the scheduler runs, it will look at your thread and only mark it as "ready to run" if that time has elapsed. This is polling, of a sort, but it's not "busy-loop" polling since it's triggered by an interrupt. It's also not that expensive: typically there are only a thousand or so threads running at a time.

This should also give you an idea why sleep times are not exact: when your thread becomes ready to run, there may be other threads that are still running and have not exhausted their time slice. Or there may be higher-priority threads that are ready to run.