Using global variables instead of Functional glabal

[prajwal.prithviraj]

Hi All ,

using gloabal varialbe instead of Funcational global in RT Vi , is this the correct method.

By creating functional global in the RT is er any draw back .

[CaravagGIO]

Hi prajwal.prithviraj,

I am a little bit confused from your question, could you please specify between which part of code do you want to communicate (deterministic loop, non-deterministic loop, two VIs)? If you meant Shared Variables and FGV please check this link http://forums.ni.com/t5/Real-Time-Measurement-and/FGV-or-Shared-Variables/td-p/299251

Best Regards,

CaravagGIO

[crossrulz]

---

@prajwal.prithviraj wrote:

Hi All ,

using gloabal varialbe instead of Funcational global in RT Vi , is this the correct method.

By creating functional global in the RT is er any draw back .

---

What EXACTLY is happening in your FGV?  If you are just doing a Set and Get, then you should just be using a global variable anyways (a lot less overhead).

But what do you need this global for?  Most times, a global is not the best method.  Often using a queue or notifier would be a better way to go.

[paul_cardinale]

If the only functions you need are reading and writing, then use a global variable.

The advantage of a functional global is that it allows other functions.

[Bob_Schor]

I posted a similar question because I remembered (not quite correctly) that "Global Variables are Evil".  As I now better understand, Global Variables are fine for the situation where you Set a value once (at the beginning of the program) and then need to Get its value multiple times from multiple places in the program.  This makes it act (and appear on the Block Diagram) as though it were a "user-defined constant".  It is a compact format, quick (faster than FGVs), and safe.

Where you do not want to use it is in situations where you need to modify the variable during the course of your program.  The reason is you can get into a "race" condition, where two pieces of code running in parallel both read, modify, and write back the Global.  Under this situation, whoever Writes Last, Writes Best. 

To illustrate, assume you try to increment the Global in one piece of code, and decrement it in another, and assume the two routines run in parallel at the same time.  If you did this using an FGV, whichever started first would finish, the other would then run, and the net result would be "No Change".  But with Globals, you'd read it twice, increment one and decrement the other, then save the incremented and decremented values to the same location, thus effectively saving the result of only the later operation.

BS

[crossrulz]

---

Bob_Schor wrote:

To illustrate, assume you try to increment the Global in one piece of code, and decrement it in another, and assume the two routines run in parallel at the same time.  If you did this using an FGV, whichever started first would finish, the other would then run, and the net result would be "No Change".  But with Globals, you'd read it twice, increment one and decrement the other, then save the incremented and decremented values to the same location, thus effectively saving the result of only the later operation.

---

I want to make something very clear here, since you did not.  The FGV will only work properly in this scenario IF AND ONLY IF the increment and decrement are part of the FGV.  At this point, you have entered the realm of an Action Engine.

I very highly recommend giving this blog post a good read: Race Conditions and Functional Global Variables in LabVIEW

[Bob_Schor]

I absolutely agree (and that's the way I use them).  To clarify, you'd create your FGV with not only Get/Set "actions", but "increment" and "decrement".  Crossrulz is right -- the key step is that the read-modify-write steps are "bound together" inside the FGV so that they have to execute in sequence without interruption of the FGV's "internal state".

Sorry for my sloppy writing ...

BS

[rolfk]

In fact if you add a "set" method to your FGV (except possibly an "init" method that is ever only called at process startup before anything else happens) only discipline can prevent you from creating the same ol race condtions that global variables suffer from. It's best to consider the "set" method "verboten" if you are going to create FGVs or Action Engines.