Instructions to sleep for a second almost never result in precisely one second’s sleep. Bob Schmidt walks us through the mechanics of why.
Suppose you are walking down the hallway of your office, and a Summer Intern (SI) intercepts you and asks, “If I put a line of code in my program that simply reads
sleep(10)
, how long will my program sleep? 1You look at the harried SI and reply, “It depends,” and you continue on your way.
The SI rushes to catch up with you, and asks, “It depends on what?”
And you answer, “That, too, depends,” as you continue walking.
At this point our young SI is frantic (and in immediate danger of going bald). “Stop talking in riddles, grey hair! I’m in real need of help here.”
Your stroll has taken you to the entrance of the break room, so you grab your interlocutor, duck inside, grab two cups of your favourite caffeinated beverage, and sit down.
“It depends,” you say, “on many things, so let’s start with first things first.”
First things first
To understand what’s going on ‘under the hood’ when a
sleep()
is executed, it helps to know a little about how CPUs work, and that means knowing something about CPU clocks, interrupts, and schedulers. The former two are hardware concepts; the latter is a software concept.
It's a decent peek under the hood for folks who usually treat such things as blackbox.
(Score: 0) by Anonymous Coward on Tuesday December 15 2015, @06:03AM
That's why where possible you should use monotonic time and not "human/clock time" for stuff that isn't to do with "human/clock time". However this is not always easily available and I blame the OS and hardware bunch for the dismal state of things. It's not like there aren't enough transistors etc nowadays to make things better.
For example at one point of time they said "don't use RDTSC" (for some CPUs the RDTSC wasn't synced) then they say "don't use the clock" and said use something like HPET if it's available, but back then it was not always available... So go figure.