‎05-06-2025 06:05 AM - edited ‎05-06-2025 06:05 AM
Hi, so I have a general question about dataflow. I was told that things can get "stuck" outside of a loop in the sense that if the loop were to execute before another operation is complete, it will not get completed until the end of the loop. I have provided an example below. In this example code the operation is simply creating an identity matrix. Assuming that I don't need the matrix in to the while loop, is it possible that the identity matrix will not be created due to the while loop potentially executing before the for loop? If so, is it necessary to force the dataflow as I do in 2)? I was under the impression that everything happens asynchronously so I don't understand how something can get stuck if this is true...
‎05-06-2025 06:14 AM
Hi asasafuchi,
@Asasafuchi wrote:
I was told that things can get "stuck" outside of a loop in the sense that if the loop were to execute before another operation is complete, it will not get completed until the end of the loop.
"Things don't get stucked": the code just follows the "THINK DATAFLOW!" mantra!
When one code blob depends on data of another code blob then it will wait for that blob to finish…
@Asasafuchi wrote:
Assuming that I don't need the matrix in to the while loop, is it possible that the identity matrix will not be created due to the while loop potentially executing before the for loop?
No, your assumption is wrong. Both code blobs will execute because they are independent…
The problem is: the WHILE loop will burn a full CPU core because it runs as fast as possible, and so it might starve other code! (This should not happen with a modern multicore CPU, but maybe you run on an old single core machine!?)
‎05-06-2025 07:05 AM
Ok thanks, so I was right in assuming that things cant get stuck because of the execution of a loop.
‎05-06-2025 10:06 AM
@Asasafuchi wrote:
.
In the top code, both independent "code islands" will execute 100% guaranteed, but in unknown order and as parallel as the hardware allows.
(If debugging is disabled, the FOR loop stack might actually run at compile time and be replaced by a constant, because the result can never change!)
In the bottom code, the While loop cannot start until the FOR loop stack is complete (which will only take nanoseconds!)
On a side note, there are better ways to create a 10x10 identity matrix (in your case it is a 2D array, though! A matrix datatype is not exactly the same), here are a few better possibilities.
‎05-06-2025 12:37 PM
You may be thinking of Event structures, especially if there are multiple ones. If one fires off and needs info from the second one, you can end up in a race condition where one loop is waiting on the other to finish, but it can't be cause THAT loop is waiting on the first one to finish. It's often due to the default setting in event structures of "Lock front panel until event completes".
The basic thing to remember is that a "container" (e.g., a For loop, While loop, Event structure, etc) will only "finish" once everything inside of it finishes. If you have a While loop with two Event structures inside it, the While loop can't finish until BOTH Event structures return. If each structure is waiting on a different task (like one each for two buttons), then it's possible to get things "stuck". (The solution in that case is to use one Event structure with multiple cases, not multiple event structures).
‎05-07-2025 01:09 AM - edited ‎05-07-2025 01:09 AM
Thanks for the good reply, I know that there are better ways of creating an identity matrix. I would never create an identity matrix the way I did in the example I provided, it was just to provide some substance of an example code that may or may not execute before the while loop.
‎05-07-2025 03:18 AM
What is more common among beginners is to place several loops inside some other loop which then won't repeat until the slowest is finished.
Another common mistake is placing a Control/input outside a loop when you want it to update during runs (else it's good design as you did), then it gets "stuck" as the input is fixed the next run.