Does each child object get its own copy of a given parent method?

[Mike Le]

I have a parent Actor with "Method A." There are several children classes which inherit "Method A."

 

If Child 1 is in the middle of running Method A and Child 2 ALSO wants to run Method A, then what happens?

 

Does Child 2 have to wait until Child 1 is done running Method A?

 

Or did Child 2 get its own copy of Method A, thus making methods inherited from a parent "semi-reentrant"?

[candidus]

Does Child 2 have to wait until Child 1 is done running Method A?

 

Yes. There's only reentrancy if you explicitly make your method VI reentrant.

In many cases this might not be a problem, though. What are you trying to accomplish?

[Mike Le]

Actually, in this case, it would be a good thing if they aren't implicitly reentrant.

 

So certain methods are forced reentrant, such as Actor Core, but new methods are not automatically set to reentrant. That's very good to know, thanks for the help!

[Aristos Queue]

To go a bit further... it wouldn't make any sense for children to have their own copy of the method... objects of a child class *are* objects of the parent class. This is the nature of the "is a" relationship we call inheritance. If you have defined a non-reentrant VI with state, you've said that all objects of the parent class should share that single state. The child class objects do not break that invariant, just as they try to not break any invariant defined by the parent class.

 

If on the other hand you have defined a method as reentrant, then you've said that every individual call gets an independent dataspace for the VI.

 

Because of this, the child, when it overrides a method, must match the reentrancy or non-reentrancy of the parent class in order to match that invariant.

[Wire Warrior]

Okay that makes me want to ask a question.  I was using a class in a dialog subVI.  The class value is passed into the subVI to be modified by the user in the pop-up.  I had based my dialog on the JKI string based state machine which has a data initialize state in the while loop.  When I placed my input class control inside the loop and my output class control outside the loop, the VI broke and the error was that re-entrant class couldnot be used that way.  When I got to looking my data accessors which were programmatically created by the IDE were set to re-entrant.  I didn't expect that to be the default behavior.

 

This is with a less than 2 week old install of LV2012 (not sp1) on a virgin machine.  Thoughts?

[Aristos Queue]

There's no such thing as a reentrant class, so that can't have been the error message. Tell me what the error message actually was and I might be able to explain. Or, better, post a picture of the broken block diagram.

[JackDunaway]

Okay that makes me want to ask a question.  I was using a class in a dialog subVI.  The class value is passed into the subVI to be modified by the user in the pop-up.  I had based my dialog on the JKI string based state machine which has a data initialize state in the while loop.  When I placed my input class control inside the loop and my output class control outside the loop, the VI broke and the error was that re-entrant class couldnot be used that way.  When I got to looking my data accessors which were programmatically created by the IDE were set to re-entrant.  I didn't expect that to be the default behavior.

 

This is with a less than 2 week old install of LV2012 (not sp1) on a virgin machine.  Thoughts?

 

(emphasis added above)

 

Maybe, you're confusing Reentrancy with Dynamic Dispatch?

 

A Dynamic Dispatch method requires class control input and output to be on the outermost diagram, and will generate the following compiler error if either is placed inside a structure: "Dynamic front panel input and output terminals cannot be placed inside structures. This ensures that they will be read from and written to exactly once so that LabVIEW can guarantee the run-time type safety of the diagram. An exception to this rule is made if the dynamic input terminal is inside a structure node and the VI has zero dynamic output terminals. In that case, the VI is not broken."

[Wire Warrior]

Okay, I completely garbled the errors.  That's what I get for hurrying.

 

There are two errors one was what Jack Dunaway posted above and the other was "Run-time type not propagted from dynamic input to dynamic output".  Making my VI non-dynamic caused that to go away.

[Aristos Queue]

Wiring from your dynamic dispatch input through to your output would also make it go away.

With a dynamic dispatch input, when you wire out of it, you'll see that the background of the wire is gray. You can wire through any number of functions and even structures along the way as long as the gray eventually reaches the dynamic dispatch output.

[Wire Warrior]

Am I right you can't bundle it into a cluster?  That would seem to be the problem it had with my use in the JKI State Machine.  Giving the dynamic class its own shift register eliminated the problem which is consistent with what you say above I think?

[Aristos Queue]

Correct. Bundling it into a cluster removes the ability to prove that the class type remains the same, which is the contract you establish when you declare a dynamic dispatch output terminal. If you have a dynamic dispatch input terminal and no dynamic dispatch output terminal, then you don't have to maintain the invariant.