Wire value changes on output tunnel

[Kevin_Price]

I follow what you're saying and find it plausible while finding my "race condition" explanation to be *also* plausible. 

However, as I rethink it yet again, I keep going back to shift registers which probably *try* to act like pointers to memory rather than copies of data whenever they're able to.  If the behavior in the original post happened with array wires in a regular loop with shift registers instead of the IPE, I'd think we'd all view it as a bug.

So now I'm starting to think that my "race condition" ideas *shouldn't* be true unless the observed behavior is a bug.  I'm gonna shout "BUG" in the subject line as bait and try to attract attention from one of the "big fish"...

- Kevin P

[mcduff]

Here is a shift register version to consider. (It is also why I think read always occurs before rewrite.)

1. Wire lengths should be irrelevant, you can resize the the wires to have different lengths.
2. I am indexing and replacing an element in an array in place.
3. I can rewrite the memory address of the element or I can read the memory address of the element. According to the diagram, there should be no order of precedence, the values from the wire should appear instantaneously at both the read and write node.
4. Yet, it appears that I always read the element before writing it, otherwise at some times the boolean would false, but it is always true.
5. That is why I believe there is a compiler rule, read first then write is there is something ambiguous, similar to the IPE structure.

LabVIEW 2015 version attached.

Not sure if this is the best analogy or example and there are probably things wrong with my reasoning.

mcduff

[Kevin_Price]

<facepalm>

I've been mostly arguing from my initial *memory* of the original post.  Unfortunately, my memory failed me.  My dumb memory kept telling me that the result of Index Array inside the IPE was showing the new updated "rewrite into" value rather than the old "read from" value.  So I was reasoning out the race condition stuff from a faulty premise.

Read before Write sounds like the correct tie-breaking rule and I agree that it's working correctly inside the IPE.

I have a new quibble though.  That indexed value is being passed out of the IPE through a regular tunnel.  In my opinion, the value seen on the wire going *into* the tunnel should match the value coming *out* of it.  That's what a tunnel is *for*, passing a *value* across a structure border.

   In this particular case, in order to assure that value constancy, a copy of the scalar value should have been made inside the IPE.  That value should have passed through the tunnel and shown up as the same value on the probe and in the indicator.

Shouldn't the regular tunnel show normal value-based behavior?  This aspect of the original example still smells buggy to me...

-Kevin P

[mcduff]

---

I have a new quibble though.  That indexed value is being passed out of the IPE through a regular tunnel.  In my opinion, the value seen on the wire going *into* the tunnel should match the value coming *out* of it.  That's what a tunnel is *for*, passing a *value* across a structure border.

   In this particular case, in order to assure that value constancy, a copy of the scalar value should have been made inside the IPE.  That value should have passed through the tunnel and shown up as the same value on the probe and in the indicator.

Shouldn't the regular tunnel show normal value-based behavior?  This aspect of the original example still smells buggy to me...

---

It seems weird  and maybe buggy, but I think it has to do with compiler rules and/or optimizations.

To me, I interpret the first diagram that the OP posted(message #1) as

1. Index the first Element of the array.
2. Replace the the first element of the array.
3. Return the memory address of the first element after the in-place optimizations have taken place.
4. So I think the compiler is replacing the element in place and returning the memory address after all of the in-place stuff occurred. Why? Because the indicator is on the outside and the compiler rule is do stuff on inside then do outside. By the time you return the value on the outside, it has changed. (Maybe passing the value is wrong, it is passing the memory address for the first element in the array.)
5. When you put the indicator on the inside, it forces the compiler to give the value at that particular point in time, before the in-place swap has occurred.

But I agree this seems confusing and non-intuitive, but maybe not a bug. Maybe just the subtle rules of the compiler that you pick up in the forums.

mcduff

[Kevin_Price]

My present, possibly faulty, understanding is that tunnels carry LabVIEW's typical *value-based* semantics.  

I agree that LabVIEW often does (and should) compile down to behavior that is much more pointer-like.  I guess that's pretty much what the smarter-than-any-single-human "In-Placeness Algorithm" is all about.  But I expect it to have to follow rules that don't break the semantics of what was put down on the block diagram to begin with.

I've never previously had any reason to think that tunnels might be treated like pointers to a memory location rather than values.  You seem fairly comfortable thinking about them that way though.  Why?   And as a thought experiment, what if the wire branched after the tunnel?  Would you think of both branches as pointers to the same memory location?  I wouldn't.  I think of them both as carrying the same value.  (While understanding that in the deep down compiled *implementation*, this doesn't necessarily require any data copying.  It would be possible for LabVIEW's by-value *semantics* to be implemented with pointers to the same memory location.)

And I guess it further strikes me that if standard LabVIEW elements like wires and tunnels can legitimately be interpreted as pointers to memory locations, then what makes DVR's so special, and why all the extra attention required to make sure they can *only* be dereferenced *inside* an IPE structure?  There are several careful protection mechanisms built into DVR access and usage to prevent problems with LabVIEW's general by-value-ness.  The lack of any such mechanisms around tunnels further confirms (in my mind) that tunnels *should* function in the normal "by value" manner.

I'm warming up to my new objection.  

-Kevin P

[mcduff]

I think the key here is that it is an ARRAY. Somewhere in whitepaper I remember reading that index array does not make a copy of the data.

Look at message #8 where I replace the element using an in-place structure in an alternative way, it gives results that you expect.

The bug/weirdness/etc I think has to do with the OP using an array in their initial message.

mcduff

[Ben]

Does moving the "New Value" outside of the IP structure change the behavior?

I ask because of two issues that may be involved.

1) The compiler seems to schedule thing that do not have any previous dependency as early as possible. With that control inside the structure there is nothing stopping that from happening so it get scheduled early.

2) Controls on the connector pane SHOULD be on the root of the diagram (see the Clear as Mud Thread). If it is not on the connector pane then the compile could be folding that operation in at compile time since it is basically a NO-OP.

No time today to do much more than share my thoughts.

Have fun!

Ben 

[Kevin_Price]

Agreed that your msg #8 is a good example to show the discrepancy in behavior.  2 different methods of extracting a single scalar element from an array.  Both scalar elements are passed out of the IPE via tunnel.  One changes value across the tunnel, the other stays the same.  I did the same mod and am including code and screencap below for others to observe, replicate, and speculate.

Meanwhile, I posted a new topic solely to try to point knowledgeable experts here.  As much as it smells like a bug to me, my spidey sense says that if such a simple test case as this can catch it, it must be considered NOT a bug or it would have been already spotted and squashed long ago.   Looking forward to reading an explanation either way.

-Kevin P

[UliB]

Hello mcduff and Kevin,

thank you both for the ongoing discussion.

---

@Ben wrote:

Does moving the "New Value" outside of the IP structure change the behavior?

---

No, it does not change. It does not matter if a control or indicator is on the connector pane or not. "New value" can even be a constant.

Just for information:

Today I opened a SRQ with NI.

[deceased]

My hunch is that mcduff's assessment is correct.

I have seen documented cases of tunnel weirdness before, such as this: https://forums.ni.com/t5/LabVIEW/When-is-dataflow-not-data-flow-Updating-LabVIEW-Arrays-through/m-p/... 

On the plus side, its giving the most up to date value, but looking at the code through normal LabVIEW eyes, it doesn't seem like that's what you asked for.

0xDEAD