LabVIEW
Understanding DVRs - II
LV2013, Win7
I'm new to Data Value References and trying to figure them out.
In the previous episode, I learned that if you use the wire that you feed to MAKE DVR somewhere else, LV will perform a COPY of whatever you feed it, and the reference refers to that copy.
That makes sense when you consider that you can MAKE DVR from a constant 5.0.
If you were to use the DVR to manipulate the value, and loop over that again, the constant 5.0 would not be 5.0 anymore, and that's just stopped. So I get it.
To access the data the DVR refers to, you have to use an INPLACE ELEMENT structure.
That performs a MUTEX operation to access the data in one place and one place only, I get it.
HOWEVER, take a look at this diagram.
The thing I want to share (via DVR) is a cluster containing an array of Sequence Elements (never mind) and a few other things.
In this code, I want to get an index for one element of that array, and extract a copy of it to display.
I have SHOW BUFFER ALLOCATIONS turned on.
I understand why I have an allocation at point #1 - I want to make a copy, and that's fine.
What I DON'T understand is why there is an allocation at #2 or #3.
The bottom is an alternate method to see if anything changed - it didn't.
If an INPLACE element has the purpose of preventing (or trying to prevent) the copying of data, and the DVR's purpose is to refer to a single instance of the data, then why is there a buffer allocation here (#2)?
It looks to me like it's making a copy of the whole structure, and then extracting a single element? Am I understanding that right?
What is a better way to copy a single element from an array via DVR?
It's quite simple.
The DVR at the input of the IPE could be invalid, might have never been created. In this case, the IPE must create a dummy set of data so that the IPE has something to do and doesn't crash the program.
This is the same reason why Indexing an array also shows a buffer allocation even if you're really super-duper careful not to index outside the valid range of the array. It's because the Compiler doesn't trust us 
.
Maybe an idea to highlight the "Possible buffer allocation" as opposed to "Definite buffer allocation" might be warranted. Maybe a diamond shape as opposed to a square or something? As an after-thought, how many different kinds of buffer allocations are there?
It has little to do with trust. The buffer allocation indication is a compile time feature. What might or might not happen during runtime can be determined by many factors, most of them are completely beyond recognition for a program without clairvoyant capabilities.
@Intaris wrote:
This is the same reason why Indexing an array also shows a buffer allocation even if you're really super-duper careful not to index outside the valid range of the array. It's because the Compiler doesn't trust us
Besides the (potential) allocation of a real data buffer there is also the allocation of a refnum, which this tool also flags as a buffer allocation, even if the underlaying object is not copied at all. And it is not even wrong, although something many people didn't expect in the first place, since every refnum also uses memory for the object reference and possible extra bookkeeping.Maybe an idea to highlight the "Possible buffer allocation" as opposed to "Definite buffer allocation" might be warranted. Maybe a diamond shape as opposed to a square or something? As an after-thought, how many different kinds of buffer allocations are there?
I'm not familiar with the IPE internals at all but principally an IPE serves as a memory barrier for the data contained in a DVR. So LabVIEW CANNOT execute the three (two) IPEs in parallel, since they operate all on the same DVR. As such the LabVIEW compiler has been pretty smart since very early on about scheduling code such that no data copies are necessary even if the wires are branched. I would expect it to realise that the IPEs are running serialized on the same refnum and therefore no copy is necessary for the DVR refnum itself.
I think the explanation from Intaris has still a lot of merit for this particular situation. It's only a potential data buffer allocation.
It also has to protect the data for other modes of the IPE, such as Index Array with Insert into Array at the right border (similar for unbundle/bundle and others). How it does that exactly (by locking the entire array access or possibly only a subset of the array that is referenced) I don't know. The first is simple to implement but can possibly lock out other parallel IPEs which want to access the same array, the second is a lot more complicated, has a significant management overhead, but allows multiple IPEs to operate on the same array, if they don't try to access the same or an overlapping range.
This is currently true even if you don't use the right node to update the value but there is a little performance improvement option coming for this. 
@rolfk wrote:
It has little to do with trust. The buffer allocation indication is a compile time feature. What might or might not happen during runtime can be determined by many factors, most of them are completely beyond recognition for a program without clairvoyant capabilities.
Well then, it's about time someone added an Idea Exchange entry for a clairvoyant compiler!
I would question the assumption that the IPE auto-generates a refnum as this buffer allocation also appears with a single IPE does it not (without sharing DVR between structures)?
