what would cause one read of a global be slower than another?

TiTou · ‎03-27-2006

Hi Ben,

Just a quick word... I don't know why I think about it so late, but I suspect your test not to be representative of what will happen in your application.
Am I wrong if I say that it's not the same ballpark if one VI reads the same global variable 1000 times (your test) or if 1000 VIs read the same global variable at more or less the same time (your application)... Isn't the global duplicated once for each VI in the second case ?

Message Edité par TiTou le 03-27-2006 01:10 PM

We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

Ben · ‎03-27-2006

Hi Titou,

You are correct. I also benchmarked 16 parallel loops. The problem was I benchmarked them in for loops.

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel

JLS · ‎03-27-2006

Hi Ben,

I think the documentation is actually clear on this point. The quote you inquired about:

"LabVIEW then sends the data back to the execution thread in a protected area of memory called the transfer buffer. LabVIEW then switches back to the execution thread. The next time the execution thread reads from the control, LabVIEW finds the data in the transfer buffer and receives the new value."

was taken from the paragraph which describes completing "user interface actions", in particular and example about writing the Value property. However, I don't think reading a global or local variable should constitute a "user interface action." Moreover, the paragraph that immediately follows this indicates that

"It is possible to update a variable multiple times before a single thread switch or user interface update occurs. This is possible because variables operate solely in the execution thread."

Given that it is possible to update a variable multiple times before a thread switch, I would hope that it is possible to read a variable without a thread switch. If the value is read into an indicator, then the indicator will require a UI update, but I don't see why a simple global read would require a thread swap. Further, the second sentence in the quote above also seems to directly support that claim, if the variables truly "operate solely in the execution thread."

I hope this helps clarify things!

Best Regards,

JLS

Best,
JLS
Sixclear

Ben · ‎03-27-2006

HI JLS,

I have read that write multiple times and it does seem to properly address the READ and UI question.

I was able to trigger timed loop "finished Late"'s by dragging a FP around with the mouse when I was using a global.

I was not able to create the "Finished Late" when the global was replaced with a LV2.

So my experimentation said it was in the UI thread.

That is why I was asking for a diffinative answer Y/N.

Iam trying real hard not to be a pain in the @#$ but it seems that somebody in NI should know the real answer to that question.

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel

JLS · ‎03-27-2006

Hi Ben,

No problem, and I totally agree that someone should know for sure! I had already inquired with R&D about this and am awaiting a response. I should have noted that in my previous post so you were aware that the question had been "escalated." And it's never a pain to want to understand LabVIEW on a deeper level - it helps everyone get a better understanding. Abstraction is a great thing sometimes, but other times we run into cases where we don't want the details hidden, because we want to make an important programming decision for which those details are important - this is one of those cases!

Thus, I look forward to a definitive answer, and posting it to this stream. If the answer is that the global READ does take place in the UI thread, then your experiments will be validated theoretically. If not, then we will have to dig a bit deeper to find an explanation for the results you have obtained.

Thank you, and I look forward to posting the official, definitive answer soon! Either way, it should be, and soon will be, documented for the masses 😉

Best Regards,

JLS

Best,
JLS
Sixclear

Ben · ‎03-27-2006

"...documented for the masses "

Excellent. I thank you!

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel

Ben · ‎03-29-2006

R&D is still thinking I guess.

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel

JLS · ‎03-29-2006

Hi again,

Well, I sincerely hope not... it shouldn't be that tough a question for a developer who's familiar with that part of the source 😉 I have probed a couple times and simply haven't heard back. I will pay a person visit and leave a post-it note if necessary - sorry for the delay on this one!

Best Regards,

JLS

Best,
JLS
Sixclear

JLS · ‎03-29-2006

Hello,

Ok, the official word is that local and global variable reads do NOT cause a thread swap to the user interface thread. That operation will occur in the thread which the VI executes. Thus, you can be sure of this by setting the execution system in the vi properties to standard. If you are willing to post the example you have referred to, I would like to see if I can produce the same affects with the same code. The task now is to understand the behavior we see given that we know a thread swap isn't forced.

As a side note, it appears the my second interpretation of the documentation was correct, as opposed to the first. For example, just because a global variable write operation may later influence a UI update, does NOT mean that it "lives" in the UI thread. In fact, the variables apparently don't "live" in any thread, rather they are shared resources which are accessible in multiple threads. Further, the statement that variables execute in the execution thread does not necessarily mean that the vi's execution thread isn't the user interface thread - in fact we can specifically force this in the vi's execution properties. In any event, we have the official word on the matter and hopefully we can come to a logical conclusion about the behavior we see which is consistent with the current information.

I look forward to your post!

Best Regards,

JLS

Message Edited by JLS on 03-29-2006 02:26 PM

Best,
JLS
Sixclear

Ben · ‎03-29-2006

Thanks JLS!

"the official word is that local and global variable reads do NOT cause a thread swap to the user interface thread."

So the plot thickens.

My brain just went into overload trying to proccess that bit of data.

Since the default (in LV 7.1) is same as caller, and since these VI's are sub-VI's of other VI's which are are all still at the default setting.....(breath)

and

Because the are all run using a "run VI" method,

What thread would they be in?

It will take me some time to get all of the VI's configured as you suggested (and I am sure the engineer will want to kill me again) when I tell him to edit 700 VI's.

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel

LabVIEW

what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?

Re: what would cause one read of a global be slower than another?