LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
elkb

Global Variable: Write Once Read Many as default

Status: Declined

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.

Global Variables are to be used with caution (see NI white paper http://www.ni.com/white-paper/5317/en ). One scenario however Write Once Read Many - is a useful and a safe one). 

 

If a global variables VI is a part of a project, LabVIEW has means to know whether there may be multiple write nodes for a global in the project (including reentrant VIs). 

 

I suggest that globals in a project be Write Once by default. In this case every attempt to add an additional write node would result in an error. "Write Many" behavior would be an option to be explicitly chosen by the programmer.

 

Not only race conditions would be excluded in this way, but the compiler can be optimized to avoid unnecessary copying of data.

 

Admittedly the same goal can be achieved with Functional Globals. However many LabVIEW users are not programmers and may never heard of that concept.

 

Similarly, adding more than one write node for a local variable should produce a warning

 

 

8 Comments
elkb
Member

Well, actually I meant not necessarily "Write once" - but "Write in one place only"

Intaris
Proven Zealot

Problems arise with dynamically loading VIs which may or may not write to a global.....

elkb
Member

For these Write in One Place Only (WOPO) globals, there may be only one place in one VI in the whole project where something is written into the global. Thus it doesn't matter if the VI is dynamically loaded. VIs from outside of the project shouldn't have access to such global at all. 

 

If you are sure you need a write access to a certain global from several places, for this global you may change the option to "Multiple Write Places Enabled" - at your own risk.

SteenSchmidt
Trusted Enthusiast

Dynamically loading would be allowed then, but reentrant setting would not. The only problem would be the dynamic VI not loading and thus never writing to the write-once global at all. But that's a programmer error.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
Alex.T
Active Participant

I think that the use of shared resources in programming and ensuring data integrity is up to the discretion of the programmer. Global Variables regardless of the programming language should immediately ring alarm bells!


Alex Thomas, University of Manchester School of EEE LabVIEW Ambassador (CLAD)

SteenSchmidt
Trusted Enthusiast

Not any more than so many other constructs. People just need to face the fact that programming isn't for amateurs 😉

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
Intaris
Proven Zealot

But how do you enforce this at run-time?  If I already have my designated writer and I want to load another VI dynamically which wants to write also, how will LV know to stop me loading the VI?  It seems that edit-time checks will not suffice to keep this idea afloat.  It will require also changes to the Run.-time environment.

 

That's what I was getting at previously.

Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.