hazards with global variables

[pitol]

Hi all,

I have a theoretical question. Is it possible to have hazardous situation when using global variables in stacked frame sequence?

Situation above is just an example. The data in global could be much more complex. Is it possible that in some case writing to global variable can last long enough to end later than reading it in the next sequence? I'm 99% percent convinced that it would never happen. Is execution of next frame waits until writing to global is finished or is it only starts the task "write to global" and then goes to next frame?

Best Regards,

Pitol

[smercurio_fc]

What is the reason for the theoretical question? My guess is that you are trying to prevent a race condition. If you are, and you are trying to use the determination of whether the write is guaranteed to finish before you do the read then I'd say you have a bigger problem on your hands. While the code you show can obviously be replaced with a wire (yes, I know it was meant for demonstration), the fact that the question is being asked leads me to believe your architecture may need a little rethought.

In terms of the question itself, the write will finish. Don't know what else to say beyond that. Like I said, I think you're asking the wrong question.

[Ben]

Forget the globals are try out Action Engines (see this link for talk of race c-onditions and how AE avoid same).

There many threads that talk of the evils of Globals (serafh for fun) but by the time you have developed code to protect the access to a global from race conditions you will find you have an Action Engine that uses a global for the storage so save the time and go for the AE.

But he big draw back (yes beyond race conditions) is each instance of the rad from global gets its own copy of the data so as you add reads of the global your performance will go down.

Trying to help,

Ben

[SteveChandler]

I cannot provide a better answer than the ones already provided. The only time that I ever use global variables is when there is at most one write. I have used them without any writes at all for some configuration stuff. You can change configuration by changing the default in the global vi. If there is ever more than one instance of the global set to write then you have to be really careful. Being really careful adds a lot of junk to your application like that shown in your example.

Answering your question would require knowing if there are any other write instances anywhere else. If while the first frame is executing something outside the structure (possibly in another VI) writes to it at the same time, then the next frame will read the value that won the race.

[pitol]

Thanks guys for your answers. The reason I posted this question is that I inherited some code which I cannot change. I've encountered a problem in very similar situation but in the end it turned out that the globals are not the reason of my problem. But anyway I was thinking about this and wanted to be 100% sure 🙂

[Ray.R]

If a wire will do the trick, use it... 

Anything that breaks dataflow (Local, Global, even a FGV/AE, StackedSequence Structure) can introduce uncertainties into the code... Uncertainties are when you run the code and get different results, usually because of race conditions.  Other uncertainties would be inccorect behavior because the data did not reach its intended destination (example:  error cluster going into a structure, but not refreshing the next iteration / page, etc..).It's not limited to the error cluster, but any variable.

The most common situation is the race condition.

The proper architecture will ensure that the code is robust, repeatable, maintainable and scalable.

[JÞB]

---

@pitol wrote:

Thanks guys for your answers. The reason I posted this question is that I inherited some code which I cannot change. I've encountered a problem in very similar situation but in the end it turned out that the globals are not the reason of my problem. But anyway I was thinking about this and wanted to be 100% sure 🙂

---

each frame of the sequence will complete all operations befor the next frame is entered.

This, as has been pointed out, only prevents race conditions within the sequence structure.  Parallel code is not protected.  "Refactor" the code that you inherited to a more stable and maintainable archetecture.  Ultimately it is a management discision.  Hope your managment is bright enough  to approve the time. 

[pitol]

I believe I have not enough "power" in my organization to make that kind of change. It is a part of some driver. I'm also not very pleased with that solution but what can I do... I have to live with it 😞

But don't worry, I'm not the fan of this solution and I try to use as best architecture as I can in all my projects.

[Ray.R]

That's all part of the fun.

Glad tyo read that you know the difference with code architecture.

[SteveChandler]

In addition to Ben's Nugget on Action Engines see "Race Conditions and Functional Global Variables" on the LabVIEW Journal. It also has a lot of good information on what a race condition really is.