🔒 Locked

Question about sleep functions

Started by Tyrone Post Mar 27, 2010 at 6:49 PM 8 replies 850+ views

Original Post

Mar 27, 2010 at 6:49 PM

I've written a small GLUT Program that draws a small box descending from the top of the screen to the bottom at a constant rate. the function, void drop(), is registered to the glutIdleFunc() function, and is implemented like this: void drop() { sleep(1); // reassign vertice coordinates.... glutPostRedisplay(); } The sleep() function, declared in unistd.h, is a unix system call (I think). Anyway, it works, however, I've defined another function void move(), registered to the glutKeyboardFunc() function, which shifts the box up, down, left, and right depending on the keyboard input. The problem is, while the sleep() function is running, the program is unresponsive to user input. So my question is, what's the work around? Will I have to multithread the app, or is there a better way to do it all together?

stonemetal

Mar 27, 2010 at 7:11 PM

Sleep is never the answer. If you want to make the box fall at a specific rate you should be getting the delta from the last time you called drop and update based on that. As it is your box doesn't fall at a constant rate it falls at a variable rate but what causes it to vary you haven't tested for(number of threads actively running on your system most likely, as well as frame rate ).

jimi_hendrix

Mar 27, 2010 at 7:21 PM

I do not mean to hijack the thread, but if you do not sleep, what prevents you from thrashing the CPU to death?

demonkoryu

Mar 27, 2010 at 8:00 PM

Quote:
Original post by jimi_hendrix
I do not mean to hijack the thread, but if you do not sleep, what prevents you from thrashing the CPU to death?

The Operating System scheduler does.

swiftcoder

Mar 27, 2010 at 8:18 PM

Quote:
Original post by jimi_hendrix
I do not mean to hijack the thread, but if you do not sleep, what prevents you from thrashing the CPU to death?

If you are programming a fullscreen game, then nobody really cares (unless they are on a portable with limited battery life). Most modern CPUs are multi-core, so unless you multi-thread your game, you still leave one or more cores free for other tasks. And lastly, the OS is there to make sure every other process gets a timeslice - it really isn't the programmer's concern.

jimi_hendrix

Mar 27, 2010 at 8:24 PM

Quote:
Original post by swiftcoder
If you are programming a fullscreen game, then nobody really cares (unless they are on a portable with limited battery life). Most modern CPUs are multi-core, so unless you multi-thread your game, you still leave one or more cores free for other tasks. And lastly, the OS is there to make sure every other process gets a timeslice - it really isn't the programmer's concern.

Thanks, I always thought it was bad when my fan kicks up and htop reads 100% on core 1. I guess I should not worry.

Tyrone Post

Mar 27, 2010 at 8:57 PM

Ok I think I've found a resolution to my problem. Let me know if this is good practice. The program is in C if that wasn't already clear.

-I've included and declared a static clock_t variable:

#include
...
static clock_t timer;

-at the begining of main, I initialize the variable with a call to clock()

int main()
{
timer = clock();
....

-In my drop function, I got rid of the sleep() call and added an if statement that compares the current time to the time stored in timer + however long I want to wait until i call postRedisplay:

void drop()
{
if ((clock()/(double)CLOCKS_PER_SEC) > ((timer/(double)CLOCKS_PER_SEC) + 1.0))
{
// reassign vertice coordinates
timer = clock();
glutPostRedisplay();
}
}

The image now responds to my input while waiting for current time to be greater than timer + 1. When the condition evaluates to true, clock() reinitializes the timer variable.

SimonForsman

Mar 27, 2010 at 9:46 PM

Quote:
Original post by jimi_hendrix
Quote:
Original post by swiftcoder
If you are programming a fullscreen game, then nobody really cares (unless they are on a portable with limited battery life). Most modern CPUs are multi-core, so unless you multi-thread your game, you still leave one or more cores free for other tasks. And lastly, the OS is there to make sure every other process gets a timeslice - it really isn't the programmer's concern.

Thanks, I always thought it was bad when my fan kicks up and htop reads 100% on core 1. I guess I should not worry.

For glut applications it should be enough to activate vsync to reduce cpu usage. (Most graphics drivers will let the cpu rest while they wait for the monitor)

swiftcoder

Mar 27, 2010 at 11:52 PM

Quote:
Original post by jimi_hendrix
Thanks, I always thought it was bad when my fan kicks up and htop reads 100% on core 1. I guess I should not worry.

Well, if you are running a laptop, then it is a bad thing, because most multi-core CPUs speedstep as a whole, and one core at 100% keeps the whole shebang at full power draw, not to mention the fan.

On a desktop, the only worries are heat and noise, neither of which tend to be a big issue in my experience.

stonemetal

Mar 29, 2010 at 3:37 PM

It rather depends on why you need to wait. If you are just trying to not fully use the CPU then vsync could be the answer. On windows I would use waitForSingleObject, so the thread yields until there are events to process or the timeout releases the wait. That way you get the best of both worlds less execution time when it isn't needed and immediate response to user input.

I guess I should have been more clear Sleep is never the answer to how to logically deal with time. You should always deal with it directly because that is the only way to get it right. Sleep provides a minimum guarantee, no maximum guarantee. Sleep's max is effected by many outside influences: OS time slice, number of threads in the system, etc. So sleep(1) and assume you came back in one is almost always wrong.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.