BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

Are globals really THAT evil?

Much more than once, I have seen people here claim that globals are the source of all evil and that they should never be used. Personally, however, I don't think the picture is so clear cut and I would like to hear a serious discussion about this once and for all (that's why I posted to the BP, BTW). Other people around here have also mentioned that they use globals for some things.
 
Let's start with the advantages. In general, I believe global variables have been benched as being the fastest method for transferring data between different VIs. They're also (in my opinion) easier to handle than other globals, because if your global is a cluster of values, you have no way of knowing where in your code you handled a specific value and if you seperate your globals then you will have to create a new file for each element. With global variables, you can just right click it and select "Find Global References".
 
The two main disadvantages in using globals are that each global will cause a copy of the data to be created and that you have a potential for race conditions or lost data. These, among with other disadvantages, like breaking the dataflow, are also shared with other types of globals.
 
So, my question to the anti-globalist movement is this - are there cases where you consider a global valid?
Specifically, if you have a single writer and multiple readers (especially where the data has an insignificant memory footprint), and you only care about the most recent values written to the global, how would you justify not using a standard global?
 
As a side issue for this, we could discuss what to tell new users. It is easier to tell them that globals are bad and to never use them than to have them come back later because they created a race condition, but I also have a feeling that this powerful "lobby" causes many users not to use a potentially easier/better tool and that it might be better to create a standard reply which properly explains the pros and cons of each method.

___________________
Try to take over the world!
Message 1 of 89
(15,294 Views)

Globals are great in certain circumstances.  If I have static data that must be shared between lots of VIs in my application, I'll use a global to store that data.  The most common example is user-visible strings...If I have a pretty complex GUI that displays messages to users all over the place, I have a single global VI with all those strings, arranged on the panel of the global in alphabetical order (by setting the tab order, I get a nice alphabetized list when dropping the global on a diagram and selecting the control I need).  This also makes it really easy if we localize this app, since there's a single VI that can be localized, instead of user-visible strings being scattered all throughout my app.

Another time I use globals is when I have a simple subpanel architecture where communication with the host VI is not required.  In these cases, the VI in the subpanel updates a global variable, which is then read later by other parts of my app.  Since no synchronization is required, and I always have one writer, globals are the way to go.

In my opinion, the time when globals should be avoided is when there are potentially multiple writers to the global.  In these cases, the potential for race conditions is too great to risk significant debugging time in the future when things just stop working correctly.

-D

Message 2 of 89
(15,288 Views)
Great answer, Darren! 🙂
 
 
Message 3 of 89
(15,280 Views)

I am glad to see someone else besides me is willing to shed some light on the proper use of globals rather than just saying to avoid them completely.  More emphasis on the proper use of globals should be given rather than the old "I'm afraid to get in trouble so I'll never use them" approach.  Education is the key.  Teach how to properly use globals, teach how race conditions are created and what to do to prevent them (besides avoiding globals).

I use globals mostly as constants.  Like holding the values of GPIB addresses.  They are created and never written to again.  No possibility of race conditions here.  Or producer consumer architecture, producer writes to the global, consumer reads it.  In this scenario, timing is important so as to have the consumer check to see if the latest read is different from the previous read.  In other words, the consumer can read twice before the global is updated, and this may not be desirable.

I feel the same way about local variables.  There is a place for them, but care has to be taken to not have a problem.  Teaching and understanding the problems that could arise and how to avoid them is the best approach by far, rather than just advocating a total ban on locals and globals.

- tbob

Inventor of the WORM Global
Message 4 of 89
(15,277 Views)
I have always viewed the prohibition against globals in the same vein as the old GOTO controversies.  Globals are useful in under the right conditions, however novice programers tend to use them inapropriately.  IMVHO, any variable (global, local, shared, or LV2) should only be used with great care.  Wires are safer.

I suppose when you get down to it, I just hate seeing the random pile of controls and indicators above or to the left 20 frame stacked sequence filled with seemingly random variable calls.  Robot Mad

And for producer-consumers, I prefer to use queue so I never have to worry about timing.
Message 5 of 89
(15,277 Views)
When using producer consumer and queues (I prefer queues to variables also), timing can still be an issue.  The consumer loop can run faster than the producer and you could try to dequeue from an empty queue, so you sometimes have to check for this.
- tbob

Inventor of the WORM Global
Message 6 of 89
(15,278 Views)


@tbob wrote:
When using producer consumer and queues (I prefer queues to variables also), timing can still be an issue.  The consumer loop can run faster than the producer and you could try to dequeue from an empty queue, so you sometimes have to check for this.

When I do that I either use the default -1 timeout, which means the loop won't iterate if there's no data, or check the timed out? terminal. That was why I specifically mentioned a single writer where you will always want only the latest value and I don't care if I lost intermediate values. I was rethinking this because of an application I'm doing now which constantly reads a single piece of data from a serial device. The VI talking to the device runs all the time and puts the most current data into the global and other VIs needing the data can read it from the global - single producer, multiple consumers and no data lost.


___________________
Try to take over the world!
Message 7 of 89
(15,273 Views)
Good subject for a discussion indeed !

Are they THAT evil... I would answer  : no, as long as you know the trick they can play.

I often recomand to avoid globals, but I do use then is some particular cases because they are indeed quite convinient. The point is that you have to know how they work to use them appropriately 😉

Use them but don't abuse them Smiley Tongue

Message Edité par TiTou le 06-15-2006 08:54 AM


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

Message 8 of 89
(15,267 Views)

@TiTou wrote:

Are they THAT evil... I would answer  : no, as long as you know the trick they can play...

The point is that you have to know how they work to use them appropriately 😉

Use them but don't abuse them Smiley Tongue


Perhaps I was mistaken in the way I presented this. This came up following some thinking I did because of something I'm working on, and so I only presented the topic of what we tell users as a side issue. Since there now seems to be a general consensus here that globals are not THAT evil I think we should now move to the part where we create a standard passage which explains the topic properly and which people can put into their macro section.

I think this is important because we should not be telling new users "don't use it because it's dangerous" (which is very easy to say), because then they will end up either never using it or ignoring what we say and deciding we're not to listened to. Instead, we should take the harder route of clarifying the dangers and advantages (and the alternatives) and letting people make their own decisions. This thread seems to be a good place for this discussion and maybe I'll start putting something together when I have some time for it. I think that we can come up with a good passage in under a week. Smiley Wink


___________________
Try to take over the world!
Message 9 of 89
(15,264 Views)


tst a écrit:

This thread seems to be a good place for this discussion and maybe I'll start putting something together when I have some time for it. I think that we can come up with a good passage in under a week. Smiley Wink


Oh yes ! Once a week, just like Darren's nuggets !

tst's discussion... You have to find a nice name for this Smiley Very Happy !

We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 10 of 89
(15,261 Views)