LVOOP object state sharing between concurrent loops in a class VI

[tadders]

Hi all, What's the best way of transfering the state of an object between 2 loops on a class VI? We have an LVOOP application where a class run method has multiple loops (one for commands sent via events and the other for harvesting data). I'm currently using a control on the diagram for the object that is updated by the state loop with a local variable read by the data loop. To ensure data integrity we have bracketed references to the control/variable by semaphores, but this seems to slow the application down. I've thought about using Global or Functional Variables, but can't see how these would be created for each instance of the object as our application can instantiate multiple objects. Any ideas? Phill

[Mark_Yedinak]

If you use a functional global I believe you will have to use an array to store the attributes for a specific instance of the object. If you use an array of clusters with one item of the cluster being some type of instance ID the functional global would have to search the array for the specific instance of the attribute data when retrieving or updating the data.

This is one thing I don't like about LVOOP. An instance of an object is not truly unique and unless you provide some type of method for maintaining instance specific attributes you don't really get a true OO design. This is the age old by value/by reference debate when it comes to LVOOP.

Message Edited by Mark Yedinak on 03-10-2010 09:43 AM

[nathand]

Sounds like you need a queue or a notifier.

[tst]

If you're using 2009, you can use a data value reference. If not, the simplest solution is a single element queue (do a search for the actual implementation).

[Mark_Yedinak]

Would each instance of the object get its own single element queue or would it get shared by all instances? I haven't played with the LVOOP enough yet to be sure of how this behaves.

[nathand]

---

Mark Yedinak wrote:
Would each instance of the object get its own single element queue or would it get shared by all instances? I haven't played with the LVOOP enough yet to be sure of how this behaves.

---

LVOOP isn't that much of a departure from standard LabVIEW, fortunately.  If you create an unnamed queue on a block diagram (even in a class), access to it is restricted to that instance of the VI and its subVIs (if the reference is wired to them).

Since the original poster is currently using a local variable, it could be easily replaced with a queue that is created within that same VI.  Each instance of that VI will get its own, independent queue.  If the data is only going one direction (one loop produces, the other consumes) then I think a notifier is easier.

[Ben]

---

Mark Yedinak wrote:
Would each instance of the object get its own single element queue or would it get shared by all instances? I haven't played with the LVOOP enough yet to be sure of how this behaves.

---

The Singleton Design pattern uses a single element queue to store the class data. The create or Init methods will create a single element queue and put the private class data in it. All methods that access the class data first read from the queue. If nobody else using it the read returns what is in teh queue the data get touched and put back when the method completes. If someone else is touching the data, the read from queue hangs until the other method completes and puts something back in the queue.

Multiple Init methods will create multiple queues one for each Init.

I think it is the Singlton Design Pattern that ships with LV as part of the examples.

The other method uses the DVR instead of the queue.

Another approach that should work that does not involve LVOOP is to use a dynamic AE and use VI Server Call by reference to act on the appropriate AE for each thread. This will be much faster than using a FP control protected by semaphores,but not as fast as teh pure LVOOP approaches.

Ben

[Mark_Yedinak]

---

nathand wrote:

---

Mark Yedinak wrote:
Would each instance of the object get its own single element queue or would it get shared by all instances? I haven't played with the LVOOP enough yet to be sure of how this behaves.

---

LVOOP isn't that much of a departure from standard LabVIEW, fortunately.  If you create an unnamed queue on a block diagram (even in a class), access to it is restricted to that instance of the VI and its subVIs (if the reference is wired to them).

Since the original poster is currently using a local variable, it could be easily replaced with a queue that is created within that same VI.  Each instance of that VI will get its own, independent queue.  If the data is only going one direction (one loop produces, the other consumes) then I think a notifier is easier.

---

From the perspective of an object you want this data to be encapsulated. Anyting outside of the object shouldn't know about this data. If you are referring to creating the queue inside a method then that applies. If you mean that the queue should be outside of the object then you are no longer using OO.

Since I haven't played that much with LVOOP I am still unsure what data is copied when the wire branchs and what is/can be shared.

[Ben]

---

Mark Yedinak wrote:

...

From the perspective of an object you want this data to be encapsulated. Anyting outside of the object shouldn't know about this data. If you are referring to creating the queue inside a method then that applies. If you mean that the queue should be outside of the object then you are no longer using OO.

Since I haven't played that much with LVOOP I am still unsure what data is copied when the wire branchs and what is/can be shared.

---

NI has carefully never said that the class wire is just a reference. If you look at the VI the LVOOP creates, you will see that they are the form where the icon connectors are on the root of the diagram and on the icon connector so the data is not necessarily copied into the LVOOP method but can be acted on in-place (see teh Clear as Mud thread).

So if you design your code such that the prvaite data is in a SR and the class data is passed through the methods and back into the SR, the data CAN live in the SR and the methods can operate on the data in the SRs.

Right up until you branch a wire.

Branching class data wires and using methods that mod the dat on the two branches, will force a daa copy and should not be done with classes that carry a lot of data. If only one of teh branches mods the data, LV can schedule the method execution such that the read happns before the data gets stepped on.

Soif you don't branch your class data and you don't un-do what the LVOOP wizrds do for you, you can ALMOST think of LVOOP as passing refs to the data.

All of the above is counter to what NI has claimed and is based on obesrvations I have made using show buffer allocations and watching my memory useage as I develop.

Ben 

[nathand]

---

Ben wrote:

NI has carefully never said that the class wire is just a reference. If you look at the VI the LVOOP creates, you will see that they are the form where the icon connectors are on the root of the diagram and on the icon connector so the data is not necessarily copied into the LVOOP method but can be acted on in-place (see teh Clear as Mud thread).

---

I'm pretty sure a class wire acts just like a cluster, with exactly the same rules about in-place operations, which items are stored inline (fixed-size data types) versus stored as references (strings and arrays), and when a copy is made.