How does sleep work, in its many variations?
The kind of sleep I'm talking about is any function that causes the thread to go into a state of sleep for a specified period of time, during which time it consumes little to no CPU.
sleep(1);
Platforms: Windows, Mac, Linux, more (maybe, don't care that much).

Any information on how these types of functions work internally would be helpful.

Er, it does exactly what you said. It tells the scheduler not to activate the thread for a certain number of milliseconds. how do i shot web?

Doesn't it work in the same way as the

rest(1);

function?

I think he means he wants to know how the code works for sleep(). I looked through sleep() in glibc, glibc/sysdeps/unix/clock_nanosleep.c and glibc/sysdeps/unix/sysv/linux/sleep.c, but it looks like a system call is made at some point so the code isnt very interesting and its very ugly :p.

Naturally it's a system call. Scheduling is done by the OS kernel. If he wants to know more he has to study the scheduler code for whatever OS he's interested in.

Some sleep tidbits:

It's been a while since I looked at this, but I know sleep's resolution varies from OS to OS. I think it's something like 20 milliseconds under Windows, and as low as 10 milliseconds under Linux. That is to say, if you ask for a sleep of 2 milliseconds your thread may not be scheduled to run again until at least 10 milliseconds have passed.

Under Linux there's also the nanosleep function, which is what I tend to use.

Finally, if you call sleep with a time of 0, it yields the thread with no minimum delay before it can reactivate - see also pthread_yield.

[EDIT]Here we go:

heh, my HZ is set to 1000, instead of the old default of 100.

Darn. I was hoping it didn't dig right into the OS like that. Oh well.
I wanted to try and write a sleep function that used a more accurate timer, but I guess that's not possible.

250 Hz here, which is 4 ms granularity. Tomasu has 1 ms...

The only issues I have with speed are my CPU frequency modulates down to 375 MHz and up to 3 GHz. I think UT 2004 caluclates the clock speed when it is running at about 1275 MHz, so one can listen to the audio in game and hear it change pitch as the frequency scales.

Unfortunately, that is true. Process scheduling is very tightly tied to the core of the operating system.

There are options available - I knew a guy who used Adeos with a Linux system to do very precise timing for mobile robotics control. I took a look at it myself, but it seems very complex. Or you could go with a Real Time OS, or something like the RealTime Application Interface for Linux. (Though I don't endorse it, as I haven't tried it. )

But none of these solutions can guarantee the timing - it's all best effort. Anything that uses a scheduler (like an OS) isn't hard real time, because if you burden the system, it can't keep up with the schedule, and your task doesn't happen when it's supposed to. Anything at the millisecond-level is very prone to error (think a couple hundred milliseconds here) depending on what you're running on other threads/processes. Though it can be quite accurate if your system is unburdened.

Example: Using a non-real time Debian Linux system, I was trying to control a robot's speed using PWM. (Turn the power on and off hundreds of times per second to set the overall speed.) It was fine, but whenever I compressed an image from the camera into JPEG, the PWMing thread wouldn't be scheduled for a few hundred millisecs. If the power was off, the robot jerked to a halt. If the power was on, WHAM! into the wall.

I don't see how it's unstable. All the scheduler has to do is check the time to see if the thread should wake up. If so, wake it up. The time being determined by a high resolution timer. What's so difficult and unstable about that?

You are forgetting that other programs are running too, which may mean the scheduler misses a few milliseconds due to those programs working.

It instructs the scheduler to get out its pocket watch and wave it in front of the thread, saying "Your going into a deep sleep", then sometimes when its in a deep hypnotic trance, the scheudle tells it to act like a chicken, and has a good laugh.

Heheheh. Try it and see what happens!

Here are two programs: ptimer and burden. Ptimer tries to cout a message every 500 milliseconds. Burden endlessly busy waits. If you run ptimer on it's own, it performs as expected. If you run ptimer and then start burden, look at the elapsed time:

I notice that if you put the window focus back to ptimer, it keeps a lot better time than if you focus on burden. Under linux, I sometimes ended up with elapsed times of more than two seconds using just one burden program!

Woah now! Before people start makign crazy assumptions about Linux multitasking and comparing it with pre-Mac OS X multitasking, let's ask what kernel version you have and what CONFIG_PREMEMPT you have:

$ gzcat /proc/config.gz |grep PREEMPT
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y

The big spike in expected times happens when burden is first started. Afterwards, it seems to be closer to 500 milliseconds than in Windows.

The fact that PREEMPT is in your kernel version is odd. I suspect it is voluntary preemption, which means that while the program is being loaded into memory (which is a system call), no other tasks can execute.

Well, show me how it runs on your computer then:

http://junction.bafsoft.com/timerdemo.zip

g++ heavyburden.cpp -o burden -Wall
g++ precisetimer.cpp -Wall

[EDIT]Voluntary preemption!? That hasn't been used since forever! I sincerely doubt that's what's going on here.

cgames@ryan ~/test/tdemo $ ./a.out
Time elapsed: 65535174 Time: 0::0
Time elapsed: 500 Time: 1152549937::174
Time elapsed: 500 Time: 1152549937::674
Time elapsed: 500 Time: 1152549938::174
Time elapsed: 500 Time: 1152549938::674
Time elapsed: 500 Time: 1152549939::174
Time elapsed: 500 Time: 1152549939::674
Time elapsed: 500 Time: 1152549940::174
Time elapsed: 500 Time: 1152549940::674
Time elapsed: 500 Time: 1152549941::174
Time elapsed: 500 Time: 1152549941::674
Time elapsed: 500 Time: 1152549942::174
Time elapsed: 500 Time: 1152549942::674
Time elapsed: 500 Time: 1152549943::174

Okay, so the test wasn't actually fair because I have two processors. Let me run two burdens now:

[append]

What are you talking about? It's still in the kernel options...

I mean that it doesn't work worth a darn, and no modern desktop OS is going to enable it by default. (I had no idea that the option to enable it even existed -- can you even run normal programs that don't manually relinquish the processor in such a system?) We are talking about the same thing, right? A scheduler that can't force a process to suspend execution and perform a context switch to let another process run? I heard very early Macs used such a system, but it bombed because every developer thought their application needed more CPU time than the others.

Sweet.

Heh, no. There are 3 preemption models in the kernel:

None: whenever a system call is executing, no task will execute until the system task finishes.
Voluntary: the kernel has some points in the code where it will voluntarily relinquish CPU. When this happens, other tasks execute.
Forced (don't know what this one is actually called, but it is what I have enabled): the kernel can be preempted anywhere where it is safe.

An additional kernel option is "preempt the big kernel lock", which adds even more opportunity for preemption.

Well I guess I shouldn't talk, I've never designed a scheduler. Seems to me like this wouldn't be an issue, but then again if they could fix it they would.

Seems to you that what wouldn't be an issue? What, you want every process to always sleep for exactly the time it wants? Not only is that not possible, it also requires far more CPU just to keep track of the processes. But if you want down to 1 ms accuracy, just adjust your kernel config (Linux; Windows you can't do anything about it).

You can adjust scheduling to 1 ms accuracy on windows.

You going to provide any more information on the subject?

Are you asking me too ?

win32::timeBeginPeriod()

Very handy. Thanks for the info. Is there any way we might be able to integrate this into Allegro? Perhaps if someone calls rest(1), call timeBeginPeriod(1) the first time it happens?

there are subtle problems that may occur whilst using this timeBeginPeriod(1)'feature'.. M$ mentions it occasionaly in there "docs" but never really gets to the point, perhaps as its a very advanced topic.

But from the limited data i have on it, i think the problems relates to possible drift, in that you dont always get exactly 1ms, which is M$ way of saying "you can ask for 1ms, and we can tell you its 1ms, but we were too stoopid to actually code it properly, so you may get something around 1ms". I think they also never mentioned it too much in the older literature because on older/slower hardware running at 1ms res caused excessive overhead and acute starvation, thereby making what programmers thought was helping actually worse; however on the newer/faster Ghz machines 1ms should be fine, i have ran 1ms on an AMD2500+ for over a year without problems, and that is a fairly old/slow machine by todays standards.

I also have test code that i use to prove it on each machine i use, and on the Ghz machines, its pretty close to 1ms.

want/need code.. just ask (i have to dig it out, so will not post yet until needed).