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

[sbus]

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?

[AristosQueue (NI)]

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]

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.  

[SteenSchmidt]

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:

Cheers,

Steen

[muks]

---

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]

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

[crossrulz]

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.

[SteenSchmidt]

---

@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

[muks]

---

- 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]

@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

[muks]

oh my misunderstanding