LabVIEW
Parallelism in LabVIEW
Solved!
Hello !
One of the important features in LabVIEW is parallelism, that may be abvious for a lot of you, but not for me. therefore, i created two VIs to test parallelism in LabVIEW, but after the test, i didn't understand what parallelism really mean in LabVIEW 
!!
I've attached a PNG file that show the code of the two VIs that i've used for the Test.
In the figure 1, there are 3 add functions. I highlighted the execution with single steping, then i noticed that LabVIEW execute the code in the following order :
1) add 3 function add C to 2 and display the result in R3.
2) add 2 function add B to 3 and display the result in R2
3) add 1 function add A to 0 and dsiplay the result in R1
This is a sequencial execution, it is not parallel !!!
.I've expected that LabVIEW will execute the add functions and display the result in the three indicators (R1,R2 and R3) all at the same time !!
Similarly in the figure 2, LabVIEW start to execute one operation in the first loop, when he is done, he move to execute in the same way, one operation in the second loop and so on until he do the same thing for all the loops, then he start again from the first loop he has executed. It seem like the processor is alocated in an equal manner for all the loops, therefore when the execution runs fastly, we see it parallel !!. Is that the meaning of paralellism in LabVIEW ??
One more question. If i execute my Test VIs in a target that can execute parallel tasks like an FPGA, and i highlight the execution, will i see something different comparing with what i've seen on my computer ???
I hope you will help me to answer my questions !
Thanks for reading my post ! 
Hi,
apart from "highlight execution":
- The main point here is THINK DATAFLOW: code is executed when the data needed to run the code is available. As long as certain parts of your code will have no data dependency (and no other way of running them sequentially like sequence frames) those parts will run in parallel.
- Another point is the number of CPU cores you have available: even when LabVIEW tries to run 100 threads in parallel it can only use as many cores as are available. On a quad core only 4 different code parts/threads can truly run in parallel…
- On a FPGA things looks different: after THINK DATAFLOW is handled then all parts of the code will run in parallel as different structures in the FPGA will handle the code. Think of the FPGA as a big bunch of different logic circuits, each one processing it's share of the code… (On a FPGA it's not the "number of cores", but the "available fabric to execute the code".)
- last edited on by
Content Cleaner
@ZRD93 wrote:
Can someone you help me to know how LabVIEW will deal with this situation ??
There are mutexes blocking the resource while it is in use. But writing to the local and global are so fast, it is practically parallel (as parallel as any two independent tasks trying to use the same CPU). And you have a classic race condition such that whoever writes to value last will win.
You might want to have a look at a document I put together: A Look At Race Conditions
- last edited on by
Content Cleaner
THE MOST IMPORTANT THING TO REMEMBER about dataflow is: Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution. (This can be found here.)
That's probably the ONLY thing you need to know. If you interpret that one sentence as literally as you can, you can figure out how your code will (or won't) run. I haven't found a case yet where it doesn't apply. Sometimes on the surface it doesn't look like it applies, but if you repeat that one sentence over and over in your head, eventually you figure it out.
- last edited on by
Content Cleaner
@ZRD93 wrote:
Thankyou dkfire and GerdW. Because of your answers, i have now a clearer understanding than before. I had like to ask one more question to make things completly clear in my mind.
I've attached a PNG file to show you a new code to test parallelism. It's a code that cause a race condition
From your answer Mr. GerdW, i understand that if i have one CPU core in my pc, LabVIEW will choose a random order to execute those 4 add operations sequentially one by one, but if i run this code on a pc that have 4 CPU cores, or on an FPGA, the 4 operations should execute simultaneously, however, it is impossible to write data at the same time in R1 indicator and R1 local variable because data will be stored in the same memory location. Similarly, we can't write in the Numeric global variable from two locations on the block diagram at the same time.
Can someone you help me to know how LabVIEW will deal with this situation ??
This is a bad example, because all your additions are computed at compile time and replaced by the result (the result is known and can never change). There is no addition happening at run time.
For each control or indicator, there are at least three copies of the data in memory: The instantaneous (1) wire value that gets copied to the (2) transfer buffer of the (3) indicator, and the data in the indicator and vice versa for controls. Indicators are updated asynchronously by the UI thread so the data needs to be held somewhere to allow the code to proceed. While the current code might seemingly always give you the same result, that order is not guaranteed to persist after any recompile or other tiny changes elsewhere, or just running on a different CPU.
The parallelism of LabVIEW is extremely powerful, but that does not mean that everything you see on the diagram runs in parallel. If you have these tiny bits of trivial breadcrumb codes, the compiler might decide to clump it together instead of trying to run it all at once because it would not make a difference and there might be other, more important things to do in parallel.
For a good introduction, read this article. NI LabVIEW Compiler: Under the Hood
