How do I make a thread run at a certain rate (x times a second ) without bothering the rest of the program?

The main-loop runs at about 1000hz and I need to output some of the data to
my screen at about 50/60Hz.
I don't care whether there are frames lost, as long as the main loop runs
correctly.

Or shouldn't I use a seperate thread for the screenoutput?

Thx

Does the output really have to be with 50Hz, or do you simply want to trigger output with a frequency of 50Hz? You could start a thread everytime that puts that stuff onto the screen, while your main loop just continues.

Apart from that you could also use a seperate thread that outputs a stack that is filled up by your main routine.

How exactly do you ensure that your main routine runs with ~1kHz? Sounds quite need-to-hack-timer-interrupt-ish :P .

Alex

nobody_ wrote:
> How do I make a thread run at a certain rate (x times a second ) without bothering the rest of the program?
> 
> The main-loop runs at about 1000hz and I need to output some of the data to my screen at about 50/60Hz.
> I don't care whether there are frames lost, as long as the main loop runs correctly.
> 
> Or shouldn't I use a seperate thread for the screenoutput?
> 
> Thx 
> 
> 

Alexander Panek wrote:
> Does the output really have to be with 50Hz, or do you simply want to trigger output with a frequency of 50Hz? You could start a thread everytime that puts that stuff onto the screen, while your main loop just continues.
> 
> Apart from that you could also use a seperate thread that outputs a stack that is filled up by your main routine.
> 
> How exactly do you ensure that your main routine runs with ~1kHz? Sounds quite need-to-hack-timer-interrupt-ish :P .
> 
> Alex
> 
> nobody_ wrote:
>> How do I make a thread run at a certain rate (x times a second ) without bothering the rest of the program?
>>
>> The main-loop runs at about 1000hz and I need to output some of the data to my screen at about 50/60Hz.
>> I don't care whether there are frames lost, as long as the main loop runs correctly.
>>
>> Or shouldn't I use a seperate thread for the screenoutput?
>>
>> Thx
>>

You probably need to be more specific about what you plan to use for drawing the output, because different libraries have different ways to achieve what you want.  For instance GLFW has a function "glfwSwapInterval()" to which you can pass the desired frame rate of your rendering.  Internally it presumably has some sort of timer and sleep call for suspending itself between renders.  I think SDL also has something like that.

--bb

Bill Baxter wrote:

>>>
> 
> You probably need to be more specific about what you plan to use for drawing the output, because different libraries have different ways to achieve what you want.  For instance GLFW has a function "glfwSwapInterval()" to which you can pass the desired frame rate of your rendering.  Internally it presumably has some sort of timer and sleep call for suspending itself between renders.  I think SDL also has something like that.
> 
> --bb

I don't want to hijack the thread, but that's not what glfwSwapInterval is for, Bill. What it does is to either turn vsync off (an arg of 0) or on (an arg of 1 or higher), vsync being the vertical retrace (i.e. the updating of the screen, scan line by scan line, from top to bottom). Passing an arg of 1 will wait for one whole vertical retrace to complete before updating the screen again. The speed of the retrace is determined by the current display mode's refresh rate (60hz, 80hz, or whatever). Calling glfwSwapInterval with a value of 1 will effectively cap the frame rate to the refresh rate (i.e. a 60hz refresh rate will cap at 60 fps), but it is not the same as running a rendering loop at 60hz per second. If you want to specify a frame rate lower than the refresh rate, the rendering loop will need to be managed manually to achieve it.

On Windows, glfwSwapInterval is a wrapper for a WGL extension. On other platforms, it may not work at all.

nobody_ wrote:
> How do I make a thread run at a certain rate (x times a second ) without bothering the rest of the program?
> 
> The main-loop runs at about 1000hz and I need to output some of the data to my screen at about 50/60Hz.
> I don't care whether there are frames lost, as long as the main loop runs correctly.
> 
> Or shouldn't I use a seperate thread for the screenoutput?
> 
> Thx 
> 
> 

I don't know what sort of application you want this for, but in principle it sounds very much like a typical game loop. Using a separate thread for constant update isn't likely not a good strategy. This article describes how to separate logic UPS (updates per second) from rendering FPS (frames per second):

http://users.telenet.be/dewitters/gameloop.html

Following that technique, you should be able to keep your 1000hz loop and have your 60hz display updates all in one thread.

>
> I don't know what sort of application you want this for, but in principle it sounds very much like a typical game loop. Using a separate thread for constant update isn't likely not a good strategy. This article describes how to separate logic UPS (updates per second) from rendering FPS (frames per second):
>
> http://users.telenet.be/dewitters/gameloop.html
>
> Following that technique, you should be able to keep your 1000hz loop and have your 60hz display updates all in one thread.
>

Sorry for my late reply (unexpected stuff :(

Won't I get into trouble when I keep everything in one thread and a
screen-update takes longer than one millisecond?
That way I could lose a loop and I really need all 1000 of them at the
correct time.

I thought that if I were to put the gfx in a different thread I could
guarantee my mainloop.
making the gfx thread idle and having some kind of thread-sleep of 20ms
every loop.

Or am I just being naive :)

"nobody_" <spam@spam.spam> wrote in message news:ejns1i$2nnk$1@digitaldaemon.com...

> Sorry for my late reply (unexpected stuff :(
>
> Won't I get into trouble when I keep everything in one thread and a
> screen-update takes longer than one millisecond?
> That way I could lose a loop and I really need all 1000 of them at the
> correct time.

Do you *absolutely* need 1000 updates per second?  What are you doing that requires such precise timing?

> I thought that if I were to put the gfx in a different thread I could
> guarantee my mainloop.
> making the gfx thread idle and having some kind of thread-sleep of 20ms
> every loop.
>
> Or am I just being naive :)

Keep in mind that even though you're using multiple threads, your code won't run any faster.  You've still got the same amount of processing power.  So if your logic loop can't keep up with the graphics in a single-threaded program, it won't be able to in a multi-threaded program either.  What you'd basically end up doing is having the graphics thread wait for the logic thread to finish its update, and they'd operate in lock step - at which point you're doing pretty much the same thing as having a single-threaded program.

> Do you *absolutely* need 1000 updates per second?  What are you doing that requires such precise timing?

Yep, eyetracking :)

>
> Keep in mind that even though you're using multiple threads, your code won't run any faster.  You've still got the same amount of processing power.  So if your logic loop can't keep up with the graphics in a single-threaded program, it won't be able to in a multi-threaded program either.  What you'd basically end up doing is having the graphics thread wait for the logic thread to finish its update, and they'd operate in lock step - at which point you're doing pretty much the same thing as having a single-threaded program.

Hyperthreading and dual core systems can handle this, right?

But first try to get it to work on a single core system :)

Lets asume I have a seperate thread for my gfx, in which I plot a hundred
pixels(idle) (no swapping/buffering)
Will this loop(of pixel putting) never be interrupted by the main
loop(critical)?
If this is the case, then I should just do some fancy stuff in one loop :)

nobody_ wrote:
>>Do you *absolutely* need 1000 updates per second?  What are you doing that requires such precise timing?
> 
> 
> Yep, eyetracking :)

You'd have some serious explaining to do before you can convince me that there is an actual need for more than 25 u/s for eye tracking.

Supposing the viewer is looking at a CRT that updates at like 120Hz, then it would be convenient to do the eye tracking at that frequency. That would be ample for the eye tracking itself, and also pretty convenient with regards to getting a tracking value for each video frame.

Lol, I would rather have a discussion about the threading...

The position on the screen isn't the only interesting part ;)
Think for instance about acceleration and microsaccades.
Plus you need at least twice the frequency af the actual wave you are trying
to measure.

Well I think thats enough about the eye.
So..
Can a thread be interrupted in the middle?
I think the awnser is yes, thus making a second thread for the graphics a
good idea.
(my second post is a bit more clear I think :)



>
> You'd have some serious explaining to do before you can convince me that there is an actual need for more than 25 u/s for eye tracking.
>
> Supposing the viewer is looking at a CRT that updates at like 120Hz, then it would be convenient to do the eye tracking at that frequency. That would be ample for the eye tracking itself, and also pretty convenient with regards to getting a tracking value for each video frame.