LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
sbus

Add "anchoring" capability to locals and globals to eliminate race conditions...

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

I would love to be able to right click on a local or a global variable on the BD and select "add anchors" to cause the object to change into one that looked like a value property node, with standard error in/out connections. The resulting object would simply pass error in to error out, but would delay execution until error in was available thereby allowing me to synchronously determine when the value would be evaluated, and eliminating the race conditions associated with local and global variables.

 

Aren't we supposed to be race-neutral anyway?

 

20 Comments
AristosQueue
Proven Zealot

Unfortunately, adding a bit of error handling would not stop the race conditions involved with locals and globals. What it would do is confuse people -- as we observe it does for Shared Variables which do have the error terminals -- about whether or not the value actually gets read when there's an error in. Everyone seems to get that it doesn't get written if there's an error in, but read is a different matter.

 

If you want to be race neutral, wire your values. Stop using variables of any kind (shared, local, global or functional).

JÞB
Knight of NI

There are good reasons to use global variables.  And if properly used they do not cause race conditions (Programmers do).  But adding error nodes?  that just slowed down a perfectly good data transfer mechanism that used to be blinding fast!  

 

Of course, you could allready put your global reads and writes in subvis with error handeling and get the exact behavior of your Idea.  And with the right Quick Drop shortcuts a RCF and some super-scripting toys you could even build yourself the tool to do exactly the implementation you discribe via a right click on the global object ( Technically feasable Idea that does not need R&D to implement)

 

But why?  "To avoid race conditions?"  Race conditions are avoided by proper programming techniques.  


"Should be" isn't "Is" -Jay
SteenSchmidt
Active Participant

Race conditions are much more than getting the data into and out of the node.

 

A) Consider a piece of code that does read-modify-write and then some other code in parallel that does a read - which value will you read?

 

B) Or if you read a value, and then wait half an hour before using that value. In the meantime you may have updated the variable numerous times, but your read has already taken place so the "other code" will eventually run with an old value.

 

Those are classic race conditions that wouldn't be helped by error terminals, but requires semaphores for instance.

 

I'd suggest the OP take a look at the VI Register toolset, they are slower but in the same order of magnitude performance-wise as locals (they are queue-based, SEQs unless buffered). The current online version doesn't support locking, but the one we're about to upload does if you need sync access:

 

VIRegister_Palette.png

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
muks
Proven Zealot

If you want to be race neutral, wire your values. Stop using variables of any kind (shared, local, global or functional).


Why not a functional global?

SteenSchmidt
Active Participant

A functional global has numerous disadvantages in this context:

 

- You need to make it, that is you physically need to create a VI and save that on disk with all that entails of having more folders and files and added maintenance.

- The overhead of calling an FG is much bigger than accessing a local (or a VI Register for that matter). It gets really bad if stuff like priority inheritance or thread switching gets involved.

- An FG is a blocking resource (as it is a non-reentrant VI), such that whenever anyone accesses it, no one else can access it.

- An FG doesn't solve the race conditions I gave as examples in my former post either.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
crossrulz
Knight of NI

Based on a certain definition of a Functional Global, that is correct.  There seems to be getting some sort of concensus that a Functional Global Variable is simply a Get and Set.  In that context, it is worse than a Global Variable.

 

Now an Action Engine is fine since you are doing something to the data only inside of the AE (the critical path of the data is protected inside of the non-reentrant VI).  This will prevent the kinds of race conditions Steen is referring to.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
SteenSchmidt
Active Participant

@crossrulz wrote:

Now an Action Engine is fine since you are doing something to the data only inside of the AE (the critical path of the data is protected inside of the non-reentrant VI).  This will prevent the kinds of race conditions Steen is referring to.

 


Only if any and all data manipulation is encapsulated inside the action engine. I'm actually always thinking FG = AE, as it's quite rare anyway only to have Get and Set. What often happens though is that an AE also has Get and Set for good measure, in addition to the different actions. And that blows the game right open to racing.

 

To sum it up: with an AE you either have complete encapsulation (with what that entails of blocking behavior), or can't guarentee it (if you have public Get and Set functions as well). In all cases a non-reentrant AE will have the same performance deficits as I wrote earlier, compared to locals, globals or VI Registers (which are inlined and thus have performance equivalent to dropping in Enqueue and Dequeue directly on your BD).

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
muks
Proven Zealot

- An FG doesn't solve the race conditions I gave as examples in my former post either.- An FG doesn't solve the race conditions I gave as examples in my former post either.

 


Can you give the link?

SteenSchmidt
Active Participant

@muks: A link to what? The race conditions I'm talking about are the A) and B) examples of my first post in this thread.

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
muks
Proven Zealot

oh my misunderstanding