LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

best way to do parallel activities

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.
0 Kudos
Message 1 of 4
(3,364 Views)
> 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.

Greg McKaskle
0 Kudos
Message 2 of 4
(3,364 Views)
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.
0 Kudos
Message 3 of 4
(3,364 Views)
....


> 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
0 Kudos
Message 4 of 4
(3,364 Views)