New Get / Set Vi's for data reference access ( Memory control / Pointer )

[manu.NET]

The new tools menu "memory control", gives,  in Labview 2009,

 the ability to create such a kind of "Pointer" to big data structure,

in order to reduce the amoung of memory needed when using many wires of an heavy datatype.

The solution provided is OK, but i thing that 2 more fonctions are needed !

For the moment the availables features are :

• Creating a reference to a datastructure
• Get/Set the content of a reference thru a "Inplace structure"
• Deleting a reference, and retrievibg it's content

It would be nice to add a "SET reference content", allowing to replace the content of the "pointer".

And also a "GET reference content", to get a wire copy of the data pointed by the reference.

For the moment, the GET and the SET can be done ... only together in the "inplace structure" ... but not separated ... 

Creating separated GET and SET would clarify Bloc diagrams ( I think ) 

Here's an example ...

[JackDunaway]

Your example just created a race condition! Uh-oh! Rearrange your wires like this and it's apparent: 

Which operation is performed first, the new Set Contents function or the Get Contents function? I'm guessing that's why NI only allows bundled In Place Read/Write operations with the global lock on the ref during the operation. Comments?

[jlokanis]

GET: branch the wire inside the inplace structure and wire it out to where ever you need the value.

SET: Have an external wire with the data to set wire into the inplace structure and use that to write the reference content, throwing away the existing value.

The whole idea of using the inplace structure is to enforce a mutex around the data the reference 'points' to so you don't mess it up with race conditions in your code.  This is simular to how we did the exact same thing in the past with single element queues.

Also keep in mind that your 'GET' operation will make a copy of the data.  If this is a large set of data and you do this 'GET' in a tight loop to peek at an element of the data, you will end up with a major problem.  The massive amount of memory allocations and free operations will bring you CPU to its knees.  The fun part of this kind of poor programming practice is the CPU will continue to be pegged for several seconds even after the VI stops running due to the 'overhang' of trying to free all those allocations.  Not a fun bug to diagnose.  So, just say NO to making data copies where ever possible.

[tst]

This is not a pointer.

Again, this is NOT a pointer.

The DVR feature allows you to have a single copy of the data because it can schedule the execution of code in such a way that every place that uses the data will use the same copy. It creates that schedule based on the IPE structure. Once you have two wires on the diagram you risk any number of things.

For example:

* Data copies.

* Race conditions (as already mentioned).

* Deadlocks (a lock waits on a release which waits on the first lock - today you have to pass the reference into the IPE structure to create this).

[manu.NET]

I know that my diagram contain "race conditions" ... but the aim of my "Posted Ideas" was to introduce the GET and the SET ... not to build a realistic application including data MUTEX ... 

A better solution of the GET could be ...

Just a question for TST ...

Are the data wire comming out of the "Delete reference" and inside the "In place Element structure" copy of the original data ?

Does these data wire have something special, something different from standard Labview wires ? (especialy those in the "replace inplace structure" ) 

For me, ( I thaught) the "data wire" is like a standard Labview wire ... so it may be a data copy ! Isn't it ?

So in all cases, because you have to extract the data from the references ... thru a wire ... you are always working with a copy ! 

Am i right or wrong ?

[AristosQueue (NI)]

> So in all cases, because you have to extract the data from the references

> ... thru a wire ... you are always working with a copy ! 

> Am i right or wrong ?

Wrong. And that's the whole point of the IPE structure. What you're working with inside the structure is the reference data directly. All other accesses to the data are locked out while you're inside the IPE, so no copy of the data is made. Assuming that the wire starts at the left side node of the structure (the "read data" node) and, passing through various modifying functions along the way, makes it across to the the "write back" node on the right side of the structure, then the "write back" node doesn't actually write the value -- the value is already updated by whatever you did on that wire.

There won't be a standalone Get and Set nodes. These are exactly the sort of things we do not want in LabVIEW because it  is so extremely easy to create performance problems and race conditions. The references as they stand in LV were added after a lot of analysis and consideration of use cases -- how could we provide the power of references in a highly parallel programming environment with the minimal probability of things going wrong.

[Darren]

Any idea that has received less than 6 kudos within 6 years after posting will be automatically declined.