Quick Question about Threads

[JesseK]

Originally Posted by apples000

My idea, which is my attempt to keep things simple, was to have a thread that would process the image, store the coordinates of the image in a variable, then wait 100ms. This would keep the processor happy. If we wanted, we could time the processing stuff then subtract that time from 100ms to make sure that we got exactly 10fps. Then, our PID loop for targeting would look to the most recently calculated image coordinate by using a method in the vision class which gets the variables with the coordinates. I realize that the PID loop may be sometimes getting bad information, for instance, it may grab the same coordinates twice before the cRIO can process another image. We used labview to do the same thing on the cRIO, and it worked fine. If my logic is flawed, I think I could just call a method which processes the image in the PID loop, which is threaded. What is the easiest way to get the image stuff working in a thread?

Why 100ms?
What happens if your image processor take 10ms to process (for a total loop time of 110ms), but the images still come in at 10Hz (every 100ms)?

Originally Posted by inkspell4

What are thread used for and do you have any resources for using them?

Threads are used to keep critical code (like your robot drive code) from being interfered with by errant processing algorithms that augment, but do not supercede, the data that the critical code uses (like image processing). Separating the threads allows for the critical code to always have enough processor to run so that the robot remains responsive. On a multi-core processor even if the image rate is increased to something obscene like 100fps, the robot drive code should still remain responsive. As far as I know, the cRIO is not multi-core -- so image rate does still matter -- yet 2-3 non-intensive threads are still great ways to ensure the non-critical data is processed separately. If there's an error in the data that causes the thread to die (uncaught exceptions anyone???) -- the thread that died should not be the main robot code thread.

However, there is no free lunch: dedicating more threads than you have CPU cores will still CPU cause scheduling conflicts. For example, if I dedicate 8 threads to heavy processing and expect my 9th main critical thread to main responsive (in a quad-core HT system), I'm really just fooling myself. The system has 7 available threads for heavy (100% cpu) processing.