www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Threads?

reply "nobody_" <spam spam.spam> writes:
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 
Nov 15 2006
next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
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 
 
 

Nov 15 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Nov 16 2006
parent Mike Parker <aldacron71 yahoo.com> writes:
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.
Nov 16 2006
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
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.
Nov 16 2006
parent reply "nobody_" <spam spam.spam> writes:
 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 :)
Nov 18 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Nov 18 2006
parent reply "nobody_" <spam spam.spam> writes:
 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 :)
Nov 18 2006
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Nov 18 2006
parent reply "nobody_" <spam spam.spam> writes:
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. 

Nov 18 2006
parent reply Paolo Invernizzi <arathorn NOSPAM_fastwebnet.it> writes:
Well, there's only one company I know that HAS a 1k/hz eyetracker ;-)
BUT 50/60 hz are pretty common...

--
Paolo Invernizzi

nobody_ wrote:
 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.

Nov 21 2006
parent "nobody_" <spam spam.spam> writes:
http://www.fourward.com/
Nov 21 2006
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
nobody_ wrote:
 Do you *absolutely* need 1000 updates per second?  What are you doing that 
 requires such precise timing?

Yep, eyetracking :)

Correct me if I'm wrong, but from what I've gathered about timing you can't have any such guarantees about getting 1ms updates on a non-realtime OS (such as windows xp), with or without threading.
Nov 19 2006
parent "nobody_" <spam spam.spam> writes:
 Correct me if I'm wrong, but from what I've gathered about timing you 
 can't have any such guarantees about getting 1ms updates on a non-realtime 
 OS (such as windows xp), with or without threading.

There are alot of microseconds in a millisecond ;) If you do countperiod/microseconds and get lucky you even get your cpuspeed. Remove as many services as possible and its possible to get really close to realtime at a millisecond level.
Nov 19 2006