Will property node cause race condition

[Flamboyant]

Will reading from and writing to a property node give rise to race conditions

[altenbach]

Short answer: No, unless you make other mistakes.

Long answer: Your question is way to vague for any clear answer....

What property? What else is going on in the program? Yes, improperly programmed you can create a race condition using a property node, especially with value properties, for example if multiple parts of your program write to it and read from it and dataflow does not fully determine in which order the various value writes and reads happen.

There must be more to your question. Do you have anything more specific in mind?

[Flamboyant]

Structure of local variable and property Node (Value)

How labview handles or manages memory between these two.

did propery node creates race conditions?

If yes or No explain resons.

Why Local variable is faster than property node.

How labview handles or manages memory between local variable and property Node (Value)

did property node(value) creates multiple copies of data in memory where ever it is used?

Any difference between using implicit property node and explicit property node if used in the same VI? 

did propery node(value) creates race conditions?why

Why Local variable is faster than property node(value).

[F._Schubert]

The value property nodes have the same potential for race conditions as local variables. But they offer you a bit more control over the execution order using the error wire. This affects only race conditions inside the same frame, which should be replaced by wires anyhow.

Property nodes are slower because they require a swap to the UI thread. I think there also might be additional data copies involved in this.

I guess you are trying to code 'variable style' like in tradtional text based programing. Maybe you should show us some piece of your code so we can point out how to do it with wires.

Felix

[altenbach]

---

LabVIEWan wrote:

Why Local variable is faster than property node(value).

---

Have a look at the explanation by DFGray here.

Quote (with emphasis added in bold):

"Property nodes are synchronous and terminals and locals are not. This, combined with the UI thread switch, makes property nodes orders of magnitude slower than terminals and locals. Every time you write a Value property node, the node waits until the action is complete. Terminals and locals, however, are cached for the next UI update cycle. The value is changed in memory, but the front panel is updated at about 60Hz. This allows much more efficient usage."

---

LabVIEWan wrote:

How labview handles or manages memory between local variable and property Node (Value)

did property node(value) creates multiple copies of data in memory where ever it is used?

---

Yes.

---

LabVIEWan wrote:

Any difference between using implicit property node and explicit property node if used in the same VI? 

---

I don't think so, but I have not done any tests.

---

@LabVIEWan wrote:

did propery node(value) creates race conditions?why

---

First, lets define what a race condition is. Have a look at the wikipedia article.

Basically, a race condition exists if the order of events is critical to the outcome, but the execution order cannot be predicted.

Many times order does not matter, thus no race condition.

As I said, a race condition is not the fault of using a property node or local variable, it is caused by shoddy programming in general.

A dataflow language such as LabVIEW depends on wires and structures to determine execution order. Any "code island" without data dependency can be scheduled to execute when CPU cycles are available. LabVIEW does not execute code from left to right or top to bottom, so if there is no data dependency, execution order cannot be predicted.

Local variables and value property nodes can break data dependency, and there are plenty of examples posted here in the forum that illustrate this. Bad examples can be found in the Rube Goldberg thread and the local variable abuse thread. A typical race condition exists if you read from a value property before it has received a useful value for elsewhere in the code.

Can you show us some code to illustrate your concern?