Global Variables with race-conditon-free option

[vitoi]

There is a debate between the use of Global Variables and Functional Globals to make variables globally available. The reasons for using a Global Variable appear to be that they are easy to use and execute faster. The reasons to use a Functional Global appear to be that they reduce data copies and avoid race conditions.

I'm only talking about Functional Globals that set and get values. Action engines are a different thing and there's the standard implementation method.

I'm not too worried about data copies as my global variables are simple and memory is cheap. However, race conditions do worry me. I assume that for a Global Variable, even if someone is accessing the variable to write to it, a reader elsewhere can read at the same time and therefore either get the earlier or later value.

The idea is to provide an option on Global Variables to make them race-condition-free (that is, same behaviour as Functional Globals). When activated, a small padlock could appear on the global to let everyone know it's race free.

You would now have pretty well all of the benefits of Functional Globals and Global Variables. Thereby putting an end to having to produce a VI, put in a loop, shift register, states, etc, just to set and get a variable. Action engines on the other hand great and worth the effort!

Maybe this Global Variable behaviour should not be an option, but the only way it operates?

[tst]

---

Maybe this Global Variable behaviour should not be an option, but the only way it operates?

---

It should, and you know what? It is. That is exactly how globals operate. The concept of earlier and later values should not be relevant, since neither mechanism is appropriate for something like this, because you can't control which instance will be called first anyway and you can't control how long the global takes to "execute".

Also, more generally, simple get-set LV2 globals don't offer any better protection against race conditions than globals. They have exactly the same problem.

Part of the problem here is that people use the same terminology to describe different things, which can cause a lot of confusion, so let's simply refer to the simple get-set type as USR globals, and personally, I don't think they offer any benefit over globals other than a false sense of security for some people. This, of course, changes the instant you put some code in the subVI. Once it has code in it, it is different from a global.

[Norbert_B]

---

@tst wrote:

Also, more generally, simple get-set LV2 globals don't offer any better protection against race conditions than globals. They have exactly the same problem.

---

Exactly this. Just adding an error cluster in and out does not protect from race conditions. It can help to reduce the risk, nothing more.

Therefore (although i am also looking for variables having an error in/out) i do not support the suggestion as-is since it will mislead esp. new user for "using variables will be free of race conditions"-thinking.

Norbert

[SteveChandler]

I would like to see an option under the edit menu or wherever to "Remove Bugs".

Sorry

[AristosQueue (NI)]

> The reasons for using a Global Variable appear to be that they are easy to use and execute faster.

> The reasons to use a Functional Global appear to be that they reduce data copies and avoid race conditions.

Wrong.

Race conditions can occur with functional globals. They are both just as inefficient.

A functional global *that never returns its internal value* is safe from race conditions. You may ask, "What the heck use is a variable if I can't get to its value!?" Well, the point is that you don't use them as *variables*. You use them as separate processes that update an internal state when called. That encapsulation of all possible modifications is what makes them safe from race conditions. If you use a functional global and do a "get value, modify in external code, then set value", you have the same problem that you have with a global VI. If you call "get value", both the global VI and the functional global will make a copy of the value.

[vitoi]

So if both Global Variables and Functional Globals (that just set and get) have equal race condition tolerance, why on earth is anyone using a Functional Global for just set and get!!!!!! And why are Functional Globals (that just set and get) so widely promoted?

Also, let me check the only use case for global variables in which I have a race condition concern. If I have a value that I want ready for handling in an event case so I put it in a Global Variable, then fire of an event, the global Variable will always be updated in time for when the event handler is executed?

[SteenSchmidt]

> why on earth is anyone using a Functional Global for just set and get!!!!!!

Are they? I don't use FGs except as action engines that operate on internal data and don't return until the modification is complete in its entirety. A Get/Set FG can protect against racing conditions if you use error terminals on the FG, use the Set and Get on the same error wire, and don't use any asynchronous data operations inside the FG. In that case you can consider the FG a serializable Global.

> If I have a value that I want ready for handling in an event case so I put it in a Global Variable, then fire of an event, the global Variable will always be updated in time for when the event handler is executed?

No, you cannot count on that. Globals are asynchronous. You must use synchronism to avoid racing conditions (wires for instance, or queues if used properly).

Cheers,

Steen

[SteenSchmidt]

> ...use the Set and Get on the same error wire...

I should add that you still need to ensure no one else is using the FG in parallel to the above, or else you still have a racing condition. So basically the Get/Set FG isn't race free in itself, it's how you use it that matters. But you can say the same about Globals.

/Steen

[SteveChandler]

Modified version of Broken Arrows image that was posted in this thread.

[vitoi]

Why did I think that LV2 Style Global Variables would prevent race conditions? ... because NI told me so!

Have a read of http://zone.ni.com/devzone/cda/tut/p/id/5317 "Are LabVIEW global variables good or bad, and when is it OK to use them?". The summary to this article by NI is:

The Summary:

• Simple datatypes with simple access patterns work great with normal globals.
• Complex access patterns can cause race conditions.
• Complex datatypes or large arrays may cause performance problems.
• Functional (LabVIEW 2 Style) globals can be used to solve both of these problems

OK, I know what they are trying to say, however it sure is easy to start thinking that Functional (LabVIEW 2 Style) globals will solve reace conditions. For those listening, just changing a Global Variable to a Functional Global will not solve race conditons.

[Peter_B]

Whether it is or isn't clear in NI's article, my summary of why NI are claiming a LV2 style global will prevent a race condition is as follows:

If your program manipulates a global variable (e.g. take a simple string concatenante function) in 2 or more places, then by placing the stringcat operation inside a LV2 global, the stringcat operation is guaranteed to complete without the data being modified elsewhere partway through that stringcat operation.