Best way to do parallel activities

Question

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.

Answer 1

> 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.
Greg McKaskle