Hi Nirmal,
I have noticed that you have been trying to help out.
Let me offer some feedback, please.
Normal globals are OK if you have a value that is written by one
entity ONLY. Multiple readers are are just fine. More than one writter
can quickly lead to race conditions so they are habitually avoided by
many experienced developers.
There is a common construct used in LV that is called by a number of
different names i.e. LV2 global or Functional global.
Do a search on this site for many discusions toughting the benifits of
a functional global.
I find that there are a number of benifits found in using these
functional globals.
The first that comes to mind is that these constructs have a diagram
so you can control exactly how they operate. (This is something that
frustrated me when I was first starting out w/LV. What do you mean I
can't get at the diagram?!)
Another benefit is that they take advantage of the nature of a
non-reentrant VI in that only one entity can access a time thereby
reducing the chances of race conditions. To do the same thing using
normal globals, you have to build the global into an action engine or
resort to using semaphores.
Next, they allow for the encapsulation of code. This is very helpful
when you have situation where some shared data structures needs to be
read, modified, and then written back. Doing this type of operation
using normal globals is a disaster waiting to happen.
Next, LV2 globals can be served from one machine to another by using
VI server techniques. Everything works the same as if the LV2 global
was on the local machine.
Next, large blocks of data can be manipulated in-place (i.e. the
operation is performed on the data in a single buffer instead of being
copied, modified and then written back). ALL of the top entries in the
LabVIEW Zone Dictionary Challenge used a variation on this construct.
So,
If the situation indicates that there is a single writter and multiple
reads, globals are fine. Otherwise a LV2 global should be concidered.
Trying to help,
Ben
