Are there any comments on the best way to do parallel activities in LabVIEW. An example is a program doing data acquisition or video capture and reading several com ports - all asynchronously. One way is to use parallel while loops and use occurrences or notifications to start each loop. I saw a posting where Sergey Krasnishov suggested vi server. Then I guess you run different instances of LabVIEW programs and use datasocket rather than local variables to exchange data between the programs. It seems to be decision as to whether you let LabVIEW determine the threading between activities (making sure not to tie up the processor in any of the parallel loops) or in the vi server case letting Windows determine which application runs wh en.
> Are there any comments on the best way to do parallel activities in > LabVIEW. An example is a program doing data acquisition or video > capture and reading several com ports - all asynchronously. One way > is to use parallel while loops and use occurrences or notifications to > start each loop. I saw a posting where Sergey Krasnishov suggested vi > server. Then I guess you run different instances of LabVIEW programs > and use datasocket rather than local variables to exchange data > between the programs. It seems to be decision as to whether you let > LabVIEW determine the threading between activities (making sure not to > tie up the processor in any of the parallel loops) or in the vi server > case letting Windows determine which application runs when.
While using multiple executables will work, there should be less overhead and less latency if you use several threads in the same executable. LV lets you assign additional threads at the subVI level. This means that you can build a subVI for the different tasks and assign different threads or priorities to the subVIs using the VI Properties.
If you have a multiprocessor computer, then with just a couple parallel loops, there will be multiple OS threads doing the execution. You can also configure LV to use more threads on a single CPU computer.
Thanks for reply. Maybe a good way is to put each of the while loops, which are to run in parallel, in separate subvis rather than on the same diagram. The subvi overhead only occurs once as the program stays inside the subvis so that shouldn't cause a delay each loop. As you say when code is in separate subvis you can assign individual priorities to each subvi. I assume this also means that if the vis, according to dataflow, occur at the same time then they are put into separate OS threads. And then if one has a multi-processor machine these will automatically be run on separate processors.
However its not clear to me if this makes better use of the processors time in terms of switching between the loops than if the 2 while loops are on the sa me diagram.
> However its not clear to me if this makes better use of the processors > time in terms of switching between the loops than if the 2 while loops > are on the same diagram. >
For deeper details on how a VI is executed, you might want to look at Steve Roger's slides from his NIWeek presentation.
A quick summary is that LV schedules execution based upon dataflow and the nodes that are ready to execute do so in what we call an execution system. Today's LV has five execution systems and each supports five priorities. In single threaded LV, there is one thread servicing the various execution systems. In multithreaded LV there can be many OS threads, each assigned to one execution system at a particular priority. Each VI has a setting/property stating where its execution is to occur, though there is some inheritance of priority to prevent inversion.
If you do not change the way LV allocates threads for the various execution systems, the default is to have one per cell, or one per execution system per priority. This means that a single VI, which runs in one execution system at one priority will use cooperative multitasking to carry out the execution of the loops.
It isn't clear to me exactly what your goal is with parallel processing, but without a second CPU, you will only have the CPU doing one thing at a time and it is a matter of how often it switches between the tasks and what precedence they tasks get. If you wish to have finer grained parallel execution, there are several techniques.
One simple one is to place a wait of zero milliseconds in each parallel operation. Each of these will cause the code to reschedule itself and if there are other operations available, they will get a turn. If not, the node will continue executing. This technique typically works very well and your diagram is in control of where the task switching occurs.
Another technique is to leave the loops in the same VI, but change the LV configuration to have multiple threads for the standard execution system. There will then be more than one OS thread that executes LV code as it becomes available. It will be up to the OS to decide everything about how the threads execute on the processor(s) available.
Another technique is to move the loops within separate VIs. Simply placing one of them in a subVI is sufficient. Then set the VI Property to have the execution take place in different execution systems. Again, more than one OS thread will be used, and ideally the behavior is indistinguishable from the first. Occasionally, two loops in the same VI will execute slower than this approach on multhprocessor computers due to cache lines on the processors and how often a write from one processor invalidates memory cached by the other processor. This difference typically goes away when debugging is turned off on the VI.