06-14-2006 10:35 AM
06-14-2006 11:02 AM
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
06-14-2006 11:24 AM
06-14-2006 12:02 PM
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.
06-14-2006 12:21 PM
06-14-2006 12:29 PM
06-14-2006 01:00 PM
@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.
06-15-2006 01:52 AM - edited 06-15-2006 01:52 AM
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
06-15-2006 02:05 AM
@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
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.
06-15-2006 02:21 AM
Oh yes ! Once a week, just like Darren's nuggets !
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.
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus