Understanding DVRs

[CoastalMaineBird]

---

@JÞB wrote:

---

---

Maybe if I create the reference from INSIDE the class, it doesn't have this weird behavior?

My understanding.

Yes, that is exactly why you are "Being Bad" by allowing anybody to create a DVR to the private data.  

The DVR is a "Location in memory where data is held" two DVRs can't point to the same location they however can point to the same data type.  And you certainly proved that creating multiple DVRs to the same class creates multiple instances of the class data. 

So, I would recommend Turning "Restrict...." back on and only allow a class member to create the DVR to pass to child.vi clones.

Your DVR Create method should only create a new DVR if the current DVR is invalid otherwise pass the valid DVR (Noting that if a DVR becomes invalid those vi's using the invalid DVR should fail)

---

I tried turning the restriction back on, and making a method.

If the method CREATES a new DVR, then I still have the same problem.

So - why not make a field in the class itself, and check for Not-A-Refnum, and then create and stash it only if needed?

Because it won't let me.  I cannot have a DVR to object X stored in object X, unless I do some typecasting shenanigans.  If I wanted to do that, I would program in C.

[JÞB]

---

@CoastalMaineBird wrote:

---

@Hooovahh wrote:

---

 I am making a new reference to a new queue, it doesn't matter if I use Obtain Queue and use the same constant wired to each of them, it will make a new reference each time.  Same here.

---

But it's a reference to the SAME QUEUE.

If I use reference A to enqueue something, I know that I can use reference B to dequeue that same something.

What I see here is it's creating a new instance.

---

Only if "Named" and in context otherwise you need the same reference to dequeue A.  Use an equality test on those references (a ref = another ref only if they refer to the same thing irrespective of the (INT) value of the ref

[CoastalMaineBird]

two DVRs can't point to the same location

Why not?

The INPLACE business is supposed to guarantee mutex access, so there's no race problems. 

[CoastalMaineBird]

---

@Hooovahh wrote:

What ever you wire into a create DVR is like splitting a wire and it will make a new copy of that data in memory.  The only difference is now you can split that DVR wire (or pass it into multiple VIs) and it won't make a new copy of the data in the DVR, but may make a new copy of the refnum which isn't that big of a deal since it is just a pointer essentially, and not the actual data.

---

OK, the light bulb is turning on.

When I SPLIT THE WIRE, I am MAKING A COPY of the data (be it an object or a boolean).

When I MAKE DVR, I am getting a reference to the COPY of that data.

LV was going to throw that copy away, but since I made a ref to it, it has to stick around.

So each child gets a reference to the COPY of the original, and NONE of them are the one that's really in the shiftReg. !

I see it now.

[CoastalMaineBird]

no, I don't quite see it all.

If SPLITTING THE WIRE is MAKING A COPY, then doesn't this give me a reference to the COPY,  where the original goes into the ShiftReg?

[JÞB]

---

@CoastalMaineBird wrote:

no, I don't quite see it all.

If SPLITTING THE WIRE is MAKING A COPY, then doesn't this give me a reference to the COPY,  where the original goes into the ShiftReg?

---

Not exactly, (Don't Hate ME!)

The compiler throws out the copy on the SR since it is "Dead Code"

[CoastalMaineBird]

The answer is YES.

Making a DVR means that you're making a COPY of the data and referencing the COPY.

The above method does not work if I also try the INCREMENT method on the class in the ShiftReg.

For the same reason.

So, how do i manage this?  Does that mean that EVERYTHING that operates on that class has to use the DVR?

[aputman]

---

@JÞB wrote:

---

@CoastalMaineBird wrote:

no, I don't quite see it all.

If SPLITTING THE WIRE is MAKING A COPY, then doesn't this give me a reference to the COPY,  where the original goes into the ShiftReg?

---

Not exactly, (Don't Hate ME!)

The compiler throws out the copy on the SR since it is "Dead Code"

---

[CoastalMaineBird]

---

@JÞB wrote:

---

The compiler throws out the copy on the SR since it is "Dead Code"

---

OK, fair enough.  But if I put a method on the one in the ShiftReg then  I have the same problem - the DVR points to one copy, the ShiftReg holds another.

[CoastalMaineBird]