LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DLL call in UI Thread blocked all property nodes.

Long time ago I had found, that when DLL, (which running in UI thread!) called, then all Property Nodes are blocked. May be it is normal behavior, but I not fully understand, why it happend? Is it documented? I can understand blocking with VI in UI thread, but why with property nodes? Espesially, if you put your property node into true case, and connect terminal to FALSE, its blocked in any case. Look, please my example, may be something wrong?
0 Kudos
Message 1 of 6
(3,733 Views)
When LV decide what thread to run a thread in, it is affected by the nodes present. The loop that is stalling has a property node so it HAS TO run in the UI thread.

The loop that does not stall, is apparently not running in the UI thread.

LV does not look at the state of your boolean before making the thread assignments. It simply asks
"Any property nodes?" if Yes, then run in UI thread.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 6
(3,733 Views)
Hello, Ben!

I understand, that my cycle with property node completely switched into UI Thread.

But can you give me any link to any NI document, which described this behavior? I my User Manual I have no found any description about this.

My opinion - it is very important, because it means, that you cannot using any property nodes (not only object, but app or VI too), or references in time critical loops, because they automatically switches my loop into UI Thread. For example, some IMAQ Vision DLLs running in UI Thread, and we have blocking of our code with these DLLs (or, probably, with other property nodes).
0 Kudos
Message 3 of 6
(3,733 Views)
I do not remeber where I learned this from.

You are correct in your observation re:using property nodes in VI's.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 6
(3,733 Views)
Ben wrote:

"I do not remeber where I learned this from."

Ben, it was here:
http://www.ltrpub.com/insideltr/tips.htm
More exactrly this tip:
http://www.ltrpub.com/pdf/tips/tip8_1.pdf

But I would like get some information from National Instruments. It must be described in details in manual.
0 Kudos
Message 5 of 6
(3,733 Views)
> LV does not look at the state of your boolean before making the thread
> assignments. It simply asks
> "Any property nodes?" if Yes, then run in UI thread.
>

I'm afraid I missed the earlier post, but to summarize how LV determines
the thread to use.

UI drawing and event handling always takes place in the UI thread.
Property nodes have to be serialized with event handling and drawing, so
they execute in the UI thread also -- many of these cause invalidation
or redrawing. A DLL node has a setting to mark them as reentrant or
not. If the DLL is not marked reentrant, then they are executed in the
UI and will compete with other UI tasks. If the DLL is thread-safe or
is only called at from one location in LV, then it can be marked
reentrant a
nd will not need to execute in the UI thread and will instead
execute in whatever thread the diagram is using.

As for making your property nodes be high priority, you can achieve this
by raising the priority of the entire process. The LV UI thread is the
main thread of the process, so nice, or the equivalent on windows is the
way to do that.

If you want other details, you might look for NIWeek presentations about
the execution system of LV.

Greg McKaskle
0 Kudos
Message 6 of 6
(3,733 Views)