Global Variable reentrant or not? (Conflicting information)

[Siniz]

Hi,

This is probably an easy questions for you veterans to answer. My question is if a Global Variable is reentrant or not. I have two conflicting sources of information. Here (http://labviewwiki.org/Functional_global_variable#Race_Conditions_and_Locking) it says:

"Global variables are reentrant. If you try to write a value to the global in several places in your code, updates to the value are unpredictable with respect to time. This means that changes to the global can be subject to race conditions. This is especially true if you read/write to the global where a race condition could occur between the read and the write of the variable."

This (http://zone.ni.com/devzone/cda/tut/p/id/4338) does however say that:

"Using global variables in time-critical priority VIs in LabVIEW Real-Time can compromise determinism. A global variable is a shared resource. If one piece of code accesses a global variable, no other piece of code can access the global variable until the first piece releases the global variable. When you block the access of a time-critical VI to a global variable, forcing the time-critical VI to wait, you introduce jitter to the application and compromise the determinism of the application."

Maybe I misunderstand this, but these two sound conflicting to me

[Mark_Yedinak]

Actually they are saying the same thing. The first is discussing stating that what data you read is not deterministic since race conditions can occur. It does not specifically address the issue the second item discusses and that is that accessing a global variable is a blocking action. If two nodes are accessing it at the same time one of them must and will wait until the other is done accessing it. One of those actors will be blocked. In a realtime system this can have dramatic effects on your timing. Both of these statements actually address a different behavor of global variables neither of which is reentrancy.

[Siniz]

Thank you for the reply Mark. I am still not sure I understand this. How can can a race condition occur, if as you say, "one of them must and will wait until the other is done accessing it" (sounds exactly like the purpose of a semaphore). This sounds like it can not incur race conditions, since it is blocked by either of the two calling functions; whichever access it first.

[Mark_Yedinak]

The race condition is that you have no control over when the data is changed or what data you will end up with. True, only one actor will be able to act upon the global variable at a time but the order which they act is undetertimed. If you have four parallel tasks that all attempt to write to the global variable at the same time only one will be allowed to actually update it at a single point in time. However the value you get at the end of all four updates is undeterministic. You will simply get the last value written. If you put other tasks into this mix that are reading the values at the same time again, you have no control over what values actually get read. Truthfully any time you can have multiple parallel actors on a shared resource you will have race conditions. This is simply the nature of parallel processing.

Message Edited by Mark Yedinak on 09-24-2009 04:00 PM

[Davidek]

Hi Siniz

Here's an example illustrating a race condition using a shared variable. I think this makes the problem very clear. The instructions are in the zip file.

Best Regards

David

NISW

[Ben]

I am going to hijack this thread and offer an alternative to the Globals that offers determinism and controls race conditions.

Use an Action Engine (Nugget found here!)

They have built-in mutexes and if set as "subroutine" they offer a "Skip Sub-VI call if Busy" to maintain determinism.

I have writtin many bad things about globals and I wrote that Nugget to help the LV Developers of the world avoid all of the hassles and problems that come from the use of globals.

Just trying to get you onto a reliable track,

Ben

[Siniz]

I very much appreciate you taking time to answer my question but I think we got a bit side tracked here. I do know about Action Enginees (I read that link and it is very good!). I do know what race conditioning is. I have read computer courses about how race conditioning happens in memory and I understand the concept.

My question was; is a  global variable re-entrant or not? I do know and have understood that it is. I am questioning what the second article link I posted says. To me it definitely sounds like it is worded as if a global variable is not re-entrant and thus, blocks other from reading/writing when it is already read/writtent to.

I think I might have understood what Mark said in his first post when he says they are saying the same thing. Is it so that the second link is describing what definitely is not good if it occurs, but it can occur if I use global vars? It sounds like explains how it works, but now when I read it again it maybe just tries to warn you of what should not occur.

[Ben]

Well OK then.

This is the best source of under-the-hood info regarding globals.

It will not answer your Q directly since reetrerancy is an idea that only applies to code and the only "code" associated with globals is reading or writting and ...

that link tells you about what is happening where and by who etc.

Sorry for the cop-out but that thread would be my source for refresher info if I was pretending to know.

Anyone want to chime in?

Ben

[JÞB]

I think I'll chime in too!

I love "globals" but I do not use them often.  Race conditions can (and will) occur just because you cannot specify the time for each call to the global.

Assume a small vi that has 1 global read updating a front panel indicator and 1 global write from a pront panel control.  Simplistically, four actions take place in this vi.  A) The Value of the Global is read (copied and put on a wire), APrime) the value is copied again and the indicator's value is written, B) the value of the front panel control is read (copied and put on a wire), B Prime) and this second value is copied again to update the value of the global variable.  The value of the vi's indicator is completely dependant on the order of execution of the 4 steps.  Because there are two wires there are two data dependancies A) the Global must be read before the indicator value is updated, B) the control value must be read before the global value is updated.  The following flows are possible (but do not include all possible orders):

Global read = Grd Control Read = Crd, Global Write= Gwr Indicator Write = Iwr & Indicator Value = Ival.

Q) Grd>Crd>Iwr>Gwr   Ival=old global value

C) Crd>Gwr>Grd>Iwr   Ival=New global value

H) Crd>Grd>Iwr>Gwr   Ival-old global value

S) Crd>Gwr>Iwr>Gwr  Ival=New global value

N) Grd>Iwr>Crd>Gwr  Ival=old global value

Since the execution order is determined at compile time the order may change each time the vi hase changes made to it.   So you go and make a minor cosmetic change and the vi behavior changes as well.  Total headache!

use Fn globals to avoid this behavior change and use globals with a bit of forethought.  (I have strict codeing standards for when I use them)

[Mark_Yedinak]

I believe most of the source of confusion comes from the first article stating that global variables are reentrant. As Ben pointed out reentrancy only applies to code, not memory. Granted LV probably has some code under the hood for accessing the global variables but conceptually the global variable is a single space in memory which can be accessed from multiple places at one time.

I would simply forget about whether or not a global variable is reentrant and accept that you run the risk of running into race conditions within your code should you use them. In addition, the access to them is blocking so you may also affecting the determinism of your code execution.