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

[TiTou]

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

[Ben]

Hi Titou,

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

Ben

[JLS]

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

[Ben]

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

[JLS]

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