Do You Realize That This is a Race Condition?

[paul_a_cardinale]

This is a race condition.  If the array contains a lot of data, it can take a while to fill in.  But the first frame doesn't wait for that.

On the other hand, writing to to the "Value" property 'seems' to work:

[santo_13]

Interesting but plausible as the UI takes time to update data into the indicator.

Never ever though such a simple code could be a race condition. Thanks for sharing with the community.

[altenbach]

This looks more like a bug. IMHO. Both should work as expected.

[Krapfen]

Agree with the knight, sequence is sequence, suppose to complete what is specified to write in, then read out.

[rolfk]

---

@Krapfen wrote:

Agree with the knight, sequence is sequence, suppose to complete what is specified to write in, then read out.

---

Nope I don’t agree! It’s a corner case but the problem here is that you access two independent buffers of the control. The local writes data to an intermediate data buffer without waiting for the UI thread to update the actual control buffer itself. Then the property comes, grabs the UI thread and prevents this thread to do the update, but reads the data from the control buffer. If you used a local, things would work as expected (and a lot faster too as the code does not have to arbitrate for the UI thread).

Unintuitive at first sight but not a bug.

And Rube-Goldberg too, also the alternative with two locals. The correct thing is of course a simple wire here!

One could argue that the property node read should check if there is a pending update from the intermediate buffer and do that first, slowing down everything even more. I would propose to add an additional wait 10ms in there to punish the Rube-Goldberg creator a little more.😀

Things can get even more interesting if the front panel is not even open. There were versions in the past that would always return the default value then. Nowadays a property node for a front panel control causes the front panel to always be loaded too independent if it gets ever opened.

[Krapfen]

Two independent buffers sounds quite intereting. I need to dig into more deep to the topic of control/indicator buffers. Thanks for sharing this useful information. 

[Yamaeda]

I haven't thought about it, but yes it is! The indicator doesn't wait for the UI thread! Sneaky one!

[Krapfen]

I used to be like reference and property so much for lots of cool settings of controls and indicators, luckly most are not that much time critical.

Here is some understanding of the memorys of actual variable and indicator/control, correct me if I am wrong.

Variable in main-thread:

data in memory are updated when the data line comes into the local variable or indicator symbol. 

Indicator in UI-Thread:

the data in variable memory are frequently checked and copied to indicator memory in the UI-Thread, if the main-thread request to read or write through Value Property Node, have to switch to the UI-Thread to get from indicator memory

Thus, in the image, when the indicator/local variable in the LV-Code (actually the variable, not the UI-indicator) receive the value, it takes time for the actual real indicator(user can see, property node can read)  to updated the indicator memory,  the main thread is way faster than the UI-Thread.

[crossrulz]

---

@rolfk wrote:

One could argue that the property node read should check if there is a pending update from the intermediate buffer and do that first, slowing down everything even more. I would propose to add an additional wait 10ms in there to punish the Rube-Goldberg creator a little more.😀

---

To force the value to be updated, you can set the Defer Front Panel Updates (which forces a UI update), do the read, and then unset the Defer Front Panel Updates.  Again, this will be super slow.

But now I'm thinking about some code I have where I do something similar to the OP, except I'm getting an indicator (graph) image instead of getting the value again.  Time to do some testing...

[crossrulz]

---

@crossrulz wrote:

But now I'm thinking about some code I have where I do something similar to the OP, except I'm getting an indicator (graph) image instead of getting the value again.  Time to do some testing...

---

Here's a test I put together.  I'll let others see if they find an issue with it.  This is a little different than the OP's situation as I am getting the image and not the value.  But this worked every time for me (ie I never got the same image, indicating the graph got updated before the image was taken).  This could point to the invoke node forcing the update before getting the image.