Can I use a global variable to stop a while loop in a subvi?

[sholm]

Can I use a global variable to stop a while loop in a subvi? I have a top VI that has 3 identical SUBVI's, the SUBVI control power supplies. I want to stop the SUBVI's with a control in the top level. If I can't use a global VI what should I use?

thanks

[RavensFan]

Yes. You can use a global variable.  Watch out for the same concerns as using local variables such as race conditions.  But if you do things properly, a global variable is an acceptable way to stop subVI's.

[DianeS]

I'd use a notifier.  You can do that one of two ways:

1.  Send the notifier reference to your subVIs through the connector pane.

2.  Name the notifier and access it by name in your subVIs.

See attached.

[sholm]

What is the race condition. Is the subvi using all the resources? I change the top level switch "off' in the front panel and if I look at the subvi front panel or block diagram it never changes states. I have the switch to latch when pushed.

[sholm]

I have Labview 2010 SP1 installed, so it's not letting me look at the examples. I tried using a notifier but have the same problem as with the global variable - i never get the change at the subvi once inside the  while loop. I will download 2011 tonight.

[SteveChandler]

---

@sholm wrote:

What is the race condition. Is the subvi using all the resources? I change the top level switch "off' in the front panel and if I look at the subvi front panel or block diagram it never changes states. I have the switch to latch when pushed.

---

See this for a description of race conditions. It is basically two things updating a common resource not knowing about the other and there is no kind of synchronization. If A sets a variable to true at the same exact time that B sets it to false then what is the value? It cannot be both. Someone has to win the race.

[JÞB]

 change the top level switch "off' in the front panel and if I look at the subvi front panel or block diagram it never changes states. I have the switch to latch when pushed.

---

A "Latching" Boolean to communicate to multiple parallel processes may not be the ideal solution.  In this case you May have a race condition (a condition where data in the storage element is not the same as the data that was previoulsy read and put on the wire when it is used) 

If you write the Global variable after the latching boolean is reset well the Global gets the rest value again (possibly BEFORE the slave loops read the Global variable.

Notifiers prevent this undesired behavior and would be a preferable method.

For an example of a race condition see the attachment.  turn on execution highlighing.  and you can see how race conditions occur

[DianeS]

Here they are in 2009, so you can see them.

[SteveChandler]

What really makes race conditions a nightmare is that you can develop code that has them and the code works reliably because the winner is always the winner. But one day you upgrade LabVIEW or modify the program slightly then it quits working. Something in your code is not behaving the same as it did before you made the change and the change seems to be totally unrelated to the thing that quit working.

Run the attached piece of code. When you press the OK button, is the indicator on or off? On my system it is always on. You would expect it to be a 50/50 chance but it is not. On your system it might be consistantly off. Maybe it is sometimes on and sometimes off on someone elses system.

The point of the overly simplified example is that if I expect pressing the button to cause the LED to be on, then the program works and always works. But when LabVIEW 2012 comes out it might do something else. If this is part of a very large project then finding it could be extremely difficult. The best defense is knowing just what a race condition is so that you can identify them.

In summary: Race conditions may not cause problems until long after you have written the code in which they exist.

[sholm]

thanks