Timing of shared variables in dynamic referenced vi's

[dems]

To answer your request for references, I would suggest you look less at the help and more at the website. Single process shared variables are described in section 2 here:
http://www.ni.com/white-paper/4679/en/

As for how sv's are asynchronous: you can test what I described and you'll see the behavior. This document seems to explain how it actually works (magic) but I've never had reason to do more than skim it:

http://www.ni.com/white-paper/12176/en/

---

 And you say that global variables can't be used by reference but I have running code (older) that shows otherwise.

---

You can definitely access shared variables by reference, but I think you would be very hard pressed to find code which uses regular globals by reference.

---

The speed of the global with the data flow of the FGV.

---

I wouldn't call it dataflow 😛 Putting error wires on the variable is no different from putting a sequence structure around your code.

As for why the FGV is worse, its probably slower by a small amount but the main thing is that its a global masquerading as a VI. Its even harder to follow than a global. I would also say that an FGV is bad in that you can leave a terminal unwired. Globals and locals both throw a compiler error if you do that (if I remember correctly). 

---

What would happen if I put several s/p shared variable running parallel in a sub-vi?

---

The compiler would magically decide what to do based on the phase of the moon etc. etc. See, magic: http://www.ni.com/white-paper/11472/en/

---

I read the blog post referenced by crossrulz and it was informative though not groundbreaking.  Based on my interpretation, I still consider my FGV to be an action engine. There are only two cases, true, but there is also a wire to explicitly tell it which case to run.  I consider the critical section to be the updating of the values contained within the FGV. 

---

But a get/set FGV isn't performing any action on the data, which is the definition of an action engine. There is no more protection of the critical section than for a global. A global ensures that you can write to memory safely and read from memory safely. An FGV does the same with more overhead. An action engine ensures you don't need to read or write to memory safely, because all the things you would be doing to that data happen inside the action engine.

Its along the lines of what Jeff said above. If you have something that just does "storage" (ie get/set ie globals/fgvs/locals/etc) then you are subject to the same risks.