Why doesn't Tick count (ms) follow Dataflow ?

Question

I have been taught basic examples of Labview data flow like multiple Add, Subtract.. blocks carry out execution at the same time and we can visually see the dataflow in Highlight execution mode.
In this example, I expect count ms to load its value the instant the first frame is run. However, in reality, count ms will only load its value to the right terminal after Search Replace string finishes (takes a long time). This means the time difference is zero !
Note that the integer constant loads the terminal the moment the frame starts, which is correct (unlike count ms)

Answer 1

zigbee1 wrote:
As a matter of fact, I have read papers that suggested splitting copies of code and wire them up at the same time hoping for "concurrent execution". This technique worked no doubt. But now I got to ask myself if they will really execute sequentially one block after another.
Concurrent execution is the normal case with code that doesn't have dataflow dependencies, but it's important to understand what that actually means. If you take the first article you linked to, it shows the transition from code, through the OS to two CPU cores:
This means that at most two instructions can actually execute in parallel. Because computers are really fast, this looks like they're doing many more things in parallel, but that's just because they're breaking them up into smaller chunks and going back and forth between them. This should give you the first clue as to what might be going on - what happens if there's a task which can't be broken up? You have a core which is stuck until that task is done. What happens if you have two such tasks at the same time? Now both cores are stuck and you can't do anything. That's why I said that LV doesn't guarantee parallel execution - it can't.
This problem doesn't actually happen at the CPU level, because operations there are relatively short and should actually have a fixed time, but it can happen at higher levels. Like I said, in this specific case, I'm guessing that the replace function does a DLL call to implement the regex functionality, and DLL calls block the thread they're in. This shouldn't apply to the majority of the primitives in LV, because I far as I know they directly generate machine code. The regex goes through a DLL because it's a standard implementation (PCRE) which isn't done by NI. Presumably other threads should keep running while this blocks.
So again, generally code which you write can execute in parallel (using at least some interpretation of the term. It might be true parallelism, it might be task-swapping), but there are cases where it won't happen. This doesn't change the functionality, but it can affect the actual execution. The reason it doesn't bother me is that it's not as common as you seem to now think it is. In fact, other than your post, I don't think I ran into something similar in quite some time.