property nodes, case structures & the UI thread

[soupy]

I was digging through the General Error Handler.vi the other day and i stumbled across this VI and it's block diagram comments.

So my questions are:

• this VI is really old. does the 2010/2011 compiler still behave the same way?
• does this compiler optimization apply to sequence structures? for & while loops? other structures?

If all of this is true, it would be really cool if NI included this in their "LabVIEW Performance" class. I took it a year ago and it wasn't.

[Josh_B1]

Hi bazookazuz,

I looked in the General Error Handler.vi on Labview 2010 and was unable to find this Set String Value.vi. I am not sure if it is because it does not exist in 2010 or if its just because I can not find it. In 2010 the General Error Handler.vi is fairly complex. Could you tell me which version you took this screen shot from and were exactly within the General Error Handler you found Set String Value. 

Regards, 

Josh Brown

[soupy]

it is in version 2010. follow the ref wire coming out of the "String to Format (not a refnum)" control and you'll find it. alternately, you can find it in the VI Hierarchy window

[Josh_B1]

Hey,

After looking into it I believe that the 2010 and 2011 compilers behave in the same way and this comment within the error handle is still valid. 

Josh Brown

[soupy]

excellent. 

how does this compiler optimization apply to other structures? (for/while loops, event structures, sequence structures, etc.) the same behavior?

[Ben]

---

@Josh B wrote:

Hey,

After looking into it I believe that the 2010 and 2011 compilers behave in the same way and this comment within the error handle is still valid. 

Josh Brown

---

Can you plese get R&D to confirm this as a fact or a falshood.

My customers get peved when I code based on beliefs that turn out to be false.

Sorry to ask for the extra effort to get R&D to confirm this fact. Remind them that "BenNI has been asking for a white paper" on this topic since the beginning of time.

From what I THINK I know*, I suspect that comment is highly questionable.

Ben

* What I think I know...

1) Property nodes have to execute in the UI thread.

2) LV attempts to minimize thread swaps.

I also beileve that my mind was set to rest when I was assured that it is ONLY the property node that executes in the UI thread (provided the VI is not set to run in the UI thread).

This thread has me sweating over what was setteled. Please clarify with R&D.

[Josh_B1]

Hi Ben,

I will take this further up and see what I can find out. 

Josh Brown

[Ben]

---

@Josh B wrote:

Hi Ben,

I will take this further up and see what I can find out. 

Josh Brown

---

Thank you sir!

The adventure should be worth the effort.

And to show that I am not just requesting meaninless knowlege, I did a search to get you started (property node thread where the search terms.) so you may want to review this thread since it covered this subject a while ago.

Ben

[Norbert_B]

Hi all,

this is quite an interesting discussion since it is based on some comment of some guy writing a LV VI (which is in fact not nicely implemented) some time ago. I don't know that person and i don't know his skills. So i have my doubts in the first instance if the comment is correct at all.......

History:

Digging into the question "When was this VI introduced" reveals that LV 6.x and older had a different GEH VI. So the VI itself is new to LV 7.0.

The code looks like this back there:

Please note that there is no additional subVI and no checking for "valid refnum". This was inserted somewhere later, i have not checked in which version. The person who moved that property node into that subVI wrote the comment in question in this discussion.

Lets see how the VI (the above screenshot is made off) is called:

Please observe the input the red arrow is pointing to. Yes, that is the reference control "String to Format (not a refnum)" from the first screenshot.

So the Property Node will always write to a NULL-refnum. This creates an error. This was "solved" by the developer by setting the execution setting to not enable automatic error handling.

The change done to the GEH was inserting a case structure around the property node to check for "not a refnum" and encapsulating the property node into a subVI. Since the subVI is never called, the question about UI thread or not is somehow obsolete in this case (nevertheless, interesting why the developer wrote that obscur comment!). In fact, that subVI including all confusion around it should be removed from the GEH.

So let's leave the discussion about this certain example "General Error Handler (GEH)" and lets talk about optimization of LV code:

It is correct, that at least as a rule of thumb (from experience): All property nodes connected to UI objects are executed in the UI thread.

So if a structure includes such a property node, there will be something running in UI thread. Nevertheless, a mechanism called clumping is taking place. Read more about clumping in the LV help under the topic "LabVIEW Threading Model".

As far as i know (and observed), clumping can split up the content of a single structure into different clumps with one exception: timed structures. Those must be a single clump (hence a single thread).

So the statement that a single property node bound to an UI object will force LV to execute the whole's structure content in the UI thread is not true, except for timed structures. Nevertheless, the chance is somehow high, that clumping does not split up the structure's content, so in many cases, the comment is true (but not in all as we have seen).

But placing the property node into a subVI in order to supress the clump to execute in the UI thread is something i doubt will work. This "disbelieve" is based on the setting of the "Set String Value.vi": It is configured to run in the "same [thread(pool)] as caller". So i find it possible the the caller is therefore executed in the UI thread as well.

All in all, the discussion shows a very important point:

Try not to use property nodes (bound to UI objects) as long as possible!

Norbert

[SynchronizationOverhead]

First, I will say that I have yet to personally test and verify this behavior, but I did look at some of the C++ source for the Clumper/ExecSystemSwitcher, so I can add some new information to Norbert's comment.

• After we have clumped nodes in the caller VI, we in-place all the nodes and sequentialize them within each clump. Then we insert ExecutionSystem switches just before a node needing a different execution system. In this case, it would be the PropertyNode (not the containing case-structure).

• A diagram must complete in the same execution system as it started, so if we switch execution systems in the middle of a diagram to call a UI-PropNode, then we must switch back at the end of the diagram. This would mean that nodes in the diagram that execute after the PropNode will also execute in the UI thread, assuming they have no other exec-sys preference. Only at the end of the diagram, or at another explicit non-UI node (like a Timed-Loop) would we switch back to the previous/new execution system.

This Clumper/ExecSys behavior, however, is pulled from the DFIR version of the Clumper (2009-2011), so I cannot confirm the behavior from 8.6 and previous versions of LabVIEW. Also, we reserve the right to change this behavior in future versions of LabVIEW.

Regarding the "put it in a subVI" "fix", I can imagine that it could have worked previously (pre-2009) to combat the reported behavior, if that was indeed the actual behavior. "Same-as-caller" is propagated top-down rather than bottom-up, so a subVI in the UI thread would not cause its callers to change, but a caller in the UI thread would force its "same as caller" subVIs to execute in the UI thread. When compiling this subVI, we would assume that it is in the "same [execution system] as caller", and not switch to the UI thread at the top-level of that subVI, instead switching only when we get to the UI-PropNode itself. If we had been propagating that up to the owning structure, this would only go up so far as the top-level diagram, and not actually set the VI itself as "UI thread". When the caller is compiling, it will not see any UI-thread nodes on its diagram, just a simple ("same as caller") subVI call, so the containing case-structure would execute in the standard/previous execution system, and only when we went into the subVI would the switch to UI occur. The "propagating a node's execution system to its parent diagram" behavior is still just speculation based on the assumption that LabVIEW used to behave the way the VI writer reports.

I have not verified this, but I do believe that the comment and subVI are no longer necessary. I will try to test this out in a debugger when I get a chance and get back to you guys.