LVOOP and reentrance

[tfritz]

Hi,

I have a question about LVOOP and reentrance. I would feel that it would be nice to have a member method to be able to execute simultaneously for different instances but only allow one at a time to execute for the same instance. Is this possible? Thinking about it a little further I'm wondering if it is even needed to forbid reentrance for the same instance, since because of the data flow there shouldn't be a case where the same method could execute simultaneously on the same object. So could you say that member functions should generally be reentrant?

Thanks,

Tobias

[Ben]

---

tfritz wrote:

Hi,

I have a question about LVOOP and reentrance. I would feel that it would be nice to have a member method to be able to execute simultaneously for different instances but only allow one at a time to execute for the same instance. Is this possible? Thinking about it a little further I'm wondering if it is even needed to forbid reentrance for the same instance, since because of the data flow there shouldn't be a case where the same method could execute simultaneously on the same object. So could you say that member functions should generally be reentrant?

Thanks,

Tobias

---

I'd say it depends on the design needs.

I developed an app that is a lot like LV using LVOOP in that users can design their own GUIs.

Each widget dropped on the FP was implemented as an active object and was realized by creating a background process from a template for each class. Vitually all of the methods used by the widgets were re-entrant to allow each widget to perform independent of all others.

BUT....

At the core of this app I used a class that created all of these widget instances and the queus required for them to interact. This "CORE" was implemented as non-re-entrant to enusre that when new widget were added or dropped (only at at edit time) no other widgets could be coming or going.

So GENERALLY yes but not always.

Have fun!

Ben

[tst]

---

tfritz wrote:

I'm wondering if it is even needed to forbid reentrance for the same instance, since because of the data flow there shouldn't be a case where the same method could execute simultaneously on the same object.

---

Exactly. You can't have the two VIs running at the same time using the same instance, because as soon as you split the wire (which is necessary for the conconcurrent run), you get a new instance.

Even so, I can't say I understand what's "nice" about the original request. Why would you want a VI to be reentrant for different instances and non-reentrant for a single instance? Is it to be able to "lock" the instance? This is essentially what all the by-ref GOOP frameworks do - they lock the cluster for each of the writing methods, so that only one method can use it at the time.

[tfritz]

Hi,

yes, that's what I thought of (locking). The by-ref-calling is nice as well (actually it seems more familiar to me as a C++ programmer). Do any of those other GOOP implementations support inheritance?

 Tobias

[tst]

Sciware GOOP does this and I believe Endevo GOOP does as well, but I haven't really used either of them, so I can't say how convenient it is. I believe you can get evaluation versions of both.

Incindentally, I don't think this only has to do with C++. There are cases where you simply need a by-ref architecture. Specifically, when you want to concurrent access to a shared resource (e.g. a comm channel to a physical device, as many people using LabVIEW tend to need). NI is well aware of this need, but I don't know what their plans are for addressing it. Currently, their method is to use the class to hold a "pointer" (or a reference, strictly speaking) to the shared resource and there's a shipping example of that. That way, creating a new instance simply creates a new copy of the reference, which still points to the same place. Personally, I feel that writing code like that is not very convenient, but that's what NI currently suggests.