Do You Realize That This is a Race Condition?

[GregR]

This is not an expected race condition. While it is true that there are separate buffers involved, LV guarantees that each operation uses the most up to date value.

• Writing to the terminal updates one of these buffers and sets additional info to say it has been updated. These both happen synchronously. Big data may take longer but that simply means the synchronous operation takes longer.
• Reading from a local or the value property checks that additional info to see if values need to be propagated before doing the read.
• The asynchronous part of UI is just the drawing to the window. The user may not see the value until later, but diagram operations provide a more strict dataflow timing.

If you can provide a VI to reproduce the behavior described, please do. That does sound like a bug.

[paul_a_cardinale]

---

@rolfk wrote:

---

@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.

---

The original wasn't Rube-Goldbergy.  The reference was passed to a sub VI; which was adjusting sizes and positions based on content.

I should have used pictures like this:

    

[paul_a_cardinale]

---

@altenbach wrote:

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

---

This raises a more general question: If a function just sends data somewhere, and doesn't return any data, is it OK for that function to return immediately without waiting for the data to get to its destination?

I tend to think it's OK.

[altenbach]

Well, i knew about the buffers but I would have expected that reading the value property would ensure that there are no pending writes to the UI.

I wonder if marking the indicator as synchronous" would make a difference (but that would also have a performance impact!).

[paul_a_cardinale]

---

@altenbach wrote:

Well, i knew about the buffers but I would have expected that reading the value property would ensure that there are no pending writes to the UI.

I wonder if marking the indicator as synchronous" would make a difference (but that would also have a performance impact!).

---

I tried that.  It didn't help.

[paul_a_cardinale]

And it's getting crazier.

In the top VI, after writing to the value property of the array, I read it back.  It always matches.  Then I call the sub VI, passing the reference to it.

In the IDE, this always works fine.  In compiled code, when the sub VI reads the value property, it always gets an empty array.

Still chasing this one.

[paul_a_cardinale]

---

@paul_a_cardinale wrote:

And it's getting crazier.

In the top VI, after writing to the value property of the array, I read it back.  It always matches.  Then I call the sub VI, passing the reference to it.

In the IDE, this always works fine.  In compiled code, when the sub VI reads the value property, it always gets an empty array.

Still chasing this one.

---

Ignore that.  In the .exe, the array isn't getting filled in.

[paul.r.r]

---

@rolfk wrote:

---

@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.

---

The documentation for this property doesn't say anything about this. If what you're describing was actually the behavior, it should be documented.

That said, I can't replicate this and I'm guessing TS has another bug that is causing him to think this is whats happening, when in reality its another issue.

[paul_a_cardinale]

---

@paul.r.r wrote:

---

@rolfk wrote:

---

@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.

---

The documentation for this property doesn't say anything about this. If what you're describing was actually the behavior, it should be documented.

That said, I can't replicate this and I'm guessing TS has another bug that is causing him to think this is whats happening, when in reality its another issue.

---

Perhaps you are right.  I can't replicate it anymore either.  When I put back that part of the code to use a terminal instead of a Value property, it still works OK.  I went back and retrieved the version just before I "fixed" it with a property node, and now that version works.

The problem was not a single observation.  During debugging, many times it happened that data went to the terminal, but didn't come out the Value property in a sub VI.

At this point I am quite baffled.  No changes have been made to the OS or to LV.  Why did it fail before?  Why does it work now?

[Intaris]

I've observed effects like this multiple times in the past.

Sometimes, LV IDE seems to have issues with some multithreaded actions. And as soon as you go looking for a repeatable test, they disappear again. Some things I've only ever noticed a single time (in 20+ years) so I'm not going to lose any sleep over it. But other things tend to pop up from time to time.

Just one of those things where the odds of it happening are so low that it's probably impossible to find and fix.

So no real input of particular value, just letting you know you're not alone in questioning what's going on.