I am not sure if this is the right place to ask the questions related to data acquisition but I would appreciate it if somebody can guide me in the right direction. I an working on an application which is collects data from a CANBUS hooked to a setup. I want to collect data and then draw some OpenGL stuff based on that data. One way to do that is to collect data and then do the analyzing stuff for GL rendering. Other suggestion I came across was to have to different programs, one to collect and the other to render stuff while the two programs are made to communicate through UDP. The second option seems better as either of the process won't slow down the other (I know UDP is not reliable in terms of data). But I want to have a single program to achieve the same results but without any lose in speed performance such that one part of the program has to wait while other is running. Can anybody please point me in the right direction here?
Using two processes that communicate over a network protocol doesn't make the process more efficient or reduce the load on the machine. It actually increases the load. The benefit is that you can run them on different computers--that's where the possible performance gain comes from.
Yeah, I was also thinking on the same lines as to what the networking protocol might be doing. What I wanted to know was that if multi-threading or anything similar could be applied to use the multicore processors and hence achieve a better performance? And if yes, then how would that be possible?
Mutlithreading is an option, this would be particularly useful if for example "ThreadA" is waiting to communicate with the device, "ThreadB" would not be prevented from executing. At the same time you would not have the same overhead that running multiple independent process would cause. All of this with the added benifit of being able to manage\kill everything from the main window if you so choose.
This takes some practice to get just right, but since you are only running three threads at once (Main Thread, ThreadA, ThreadB) you shouldn't run into too much trouble.