Jump to content

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


Recommended Posts

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"?

Link to comment

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!

Link to comment

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.

Link to comment

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?

Link to comment
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."

Link to comment

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.

Link to comment

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.

Link to comment

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.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.