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

[Ben]

After thinking about it, I will call this issue dead.

I am not going to have the engineer go through and change all of those VI's to get an experiment involving the globals together. I think all of my issues have been addressed and the only remaining mystery was why the "Finished Late" flags could be "encouraged" by dragging a screen. Globals reads in the UI thread could have explained that.

My application is satisfactory without the globals and I am "off the [global] bandwagon" for another 5 years.

Ben

[JLS]

Hello again,

Too bad it'll go away without a good explanation.  We never like to finish issues on a "it must be something else in the code" note... but with a huge application, sometimes that's the only practical option.  It's a good think this stream started anyway, so that at least we have confirmed that variable reads don't require a UI thread swap.

Thanks for hanging with this one for the couple days it took to get an official answer from R&D.

Best Regards,

JLS

[crelf]

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

Wow!  When did this change?

[JLS]

Hello,

I have pinged R&D about the history of global variable behavior, and I'll post anything interesting here!

Best Regards,

JLS

[JLS]

Hello again everyone,

I have some more specific information.  First, there is a thread protection mechanism to make sure that no writer of the global is changing the data while you are reading it, but this is done via a mutex, and not by going to the UI thread. However, if the Global variable panel is opened, then a message is posted to redraw the global control, and the redraw will happen in the UI thread.

For the history of the feature, before LV5, LV was single threaded, so everything happened in the UI thread. Built-in globals were added in LV3.1, so between LV3.1 and LV5, globals, like everything else, happened in the UI thread. Today, they happen in the execution system's thread. LabVIEW checks to make sure no writer is in progress, then copies the global to the local diagram's memory, then releases the lock so that a writer can have access.

Best regards and happy LabVIEW programming!

JLS

Message Edited by JLS on 04-04-2006 01:21 PM

[parthabe]

Great conversation about globals !

[Yamaeda]

(I might mention already written stuff, i've only read 2 pages)

2 ideas that hit me while reading:
- The notifier idea isn't primarily about reading time, but reaction time. You mentioned you had lots of loops at 100 hz? Then the notifier is fast, but the question is how fast it'll react to a notifier change. The LV2/AE/FGV has a reaction time of 1 loop, a notifier can stop the loop 'early' by connecting the loop stop to timeout. Your test doesn't really simulate this.

- Have you tried setting the FGV as sub-vi priority?

/Y

[Ben]

---

Yamaeda wrote:
(I might mention already written stuff, i've only read 2 pages)

2 ideas that hit me while reading:
- The notifier idea isn't primarily about reading time, but reaction time. You mentioned you had lots of loops at 100 hz? Then the notifier is fast, but the question is how fast it'll react to a notifier change. The LV2/AE/FGV has a reaction time of 1 loop, a notifier can stop the loop 'early' by connecting the loop stop to timeout. Your test doesn't really simulate this.

- Have you tried setting the FGV as sub-vi priority?

/Y

---

This thread is quite old but to re-cap...

It was a test to see if the Globals would perform without issues.

LV2's (Action Engines) did not show a problem.

Tossing the globals and switching the the AE version solved the "finished late" problem.

So...

It was only the global reads that were exibiting the issue of "Timed Loop Finished Late".

Ben

[Yamaeda]

You've solved the problem so it's kind of beating a dead horse i assume, but just for fun: You were abit concerned about the performance, so i did a small test. Everyone talks about AE's, but how many change the priority of this vi? Maybe it's just me being dull (but then the application i'm working with currently isn't time critical) but i cant remember any tips'n'trix to make AE's Subroutines.

Well, i just tested it for fun, and a small loop of 100k reads went from 54ms (standard) to 4ms (subroutine)! I cant be the only one that's missed that. 😉

/Y

[Ben]

---

Yamaeda wrote:
You've solved the problem so it's kind of beating a dead horse i assume, but just for fun: You were abit concerned about the performance, so i did a small test. Everyone talks about AE's, but how many change the priority of this vi? Maybe it's just me being dull (but then the application i'm working with currently isn't time critical) but i cant remember any tips'n'trix to make AE's Subroutines.

Well, i just tested it for fun, and a small loop of 100k reads went from 54ms (standard) to 4ms (subroutine)! I cant be the only one that's missed that. 😉

/Y

---

We discussed that during the Bit-Twiddler and Dictionary Challenges but if you weren't around back then it is good that you have brought that up again.

Setting an AE to sub-routine is good after it has been debugged IF POSSIBLE. In the simple case of a shutdown or stop falg this is fine. If the AE has any type of I/O wrapped up in it (file I/O or other asyncronous stuff) sub-routine is not an option.

Thank you,

Ben