Functional Global Variable vs. Shared Variable

[Z4CRUZN]

So I find myself dealing with a real-time application that uses functional globals (It is a QSM Queued State Machine architecture). A bit new to them, but from what I understand (from my reading about them) is that they are useful in applications where you are writing to these variables simultaneously  from many .vi's, which we are in this case. The shift register action in the loop, effectively locks down the variable from reading or writing, untill either of those operations is complete. It helps to prevent a race condition. However, for most of my Labview time (around 4 years or so) I was always told to use shared variables for everything. If nothing else, it is easy to see that you now have a list of variables in project explorer. I thought that I read that there is a setting with shared variables that effectively makes them like a global variable. So when this setting is used, is there any real difference? Thanks....

Dan

[JÞB]

Dan,

Language constructs do not create race conditions.  Bad programming does.

It is possible to create race conditions with global, shared or FG variables.  The key to avoiding race conditions is blocking critical segments of code.

Global variables make it easy to create race conditions.  FGVs make it a bit harder since the developer made the FGV for a reason- and thought more about data and data access.  Shared Variables have the same advantage- The developer thought about the data.  But it is not the same thing as preventing race conditions. 

You have to think about the bigger problem.......... How can I limit access to this data to the functions that must operate on it?

When you limit that scope- you do what any programmer should do... Limit the project from doing whatever is possible to doing what is reasonable for this project.

[crossrulz]

---

@Z4CRUZN wrote:

However, for most of my Labview time (around 4 years or so) I was always told to use shared variables for everything.

---

Whoever told you that should be shot.  Shared variables are basically the same as global variables, except with more overhead.

Ok, shared variables are exactly like globals when you make them single process.  But they still have more overhead than the simple global (or so I have been told).

With the Network Published Shared Variables, you have to be even more careful because ANYBODY ON THE NETWORK can change your data.  Talk about race condition city!  A proper communication chain should be used instead (UDP, TCP/IP, Network Stream) to that your data is protected by the only process that can write to it.

As far as the Functional Global Variable preventing race conditions, that really depends on how you use them.  As Jeff said, the important thing is protecting the critical sections of code.  If your FG is just a Set Value/Get Value, then you just made something exactly like a global variable but with more overhead.  This means that you are not protecting any critical path.  But if you are performing tasks on the data only inside of the FG, then you are protecting the critical sections.  We like to call these Action Engines.