Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

passing data to nested actors

when passing data to nested actors, I have a feeling that the proper thing to do is to pass all data to any nested actor in a message(s). I just don't know why that would be preferred, as opposed to for example wiring the data directly to the actor using the nested actor's data access methods. can anyone please shed some light on this.

0 Kudos
Message 1 of 9
(5,598 Views)

If you are passing data to the nested actor before it's launched, then direct accessor methods on the actor wire work just fine. I use this to pass init info to the nested actor before I launch it. If you're trying to pass data to the nested actor after launching, well, you have to use messages. There's no way to directly add data to a nested actor's object...it's running in a separate process. That object instance is no longer available to the calling actor, only the enquerer is available.

0 Kudos
Message 2 of 9
(4,839 Views)

thank you, your response is so obvious now that i'm thinking about it, i feel silly for asking the question. I was doing what you described, passing data directly before launching the nested actor as I tend to launch and stop my actors frequently. Is that ok, to launch and stop actors at will as i see fit?

0 Kudos
Message 3 of 9
(4,839 Views)

better to ask than to wonder for hours

0 Kudos
Message 4 of 9
(4,839 Views)

> . Is that ok, to launch and stop actors at will as i see fit?

If it works for you, fine. Telling the nested actor to stop, waiting for it in the Last Ack, adjusting its parameters, and then relaunching it works, from a purely functional point of view.

There's performance overhead associated with launching and stopping an actor, more than just sending a message. And if the actor needs to be doing something while it is receiving messages, then stopping and restarting will probably cause problems. And, obviously, if the nested actor has its own nested actors, there could be a lot of churn in that restart.

I've never had the need for such a pattern, but there's nothing inherently dangerous about that path other than performance.

0 Kudos
Message 5 of 9
(4,839 Views)

Thanks for the explanation, as i'm rather new to this way of coding. I must say that i'm beginning to notice that some things, certain tasks just don't lend themselves nicely to being made into stand-alone actors, some do but some certainly don't, at least in my mind, again please respond if you disagree, that's how I learn what's cool or not, to do with actor framework... example being... things that need to be done only once, or perform one task, every so often, as prompted by the user. One thing is for sure, I really appriciate in your response the statement you made about not ever needing to start and stop actors at will, and I'm not so concerned about the overhead, if needed i'll get faster computer and more memory, but what you've shared in that one comment is a certain coding mind set, which is what i need to get more efficient with actors. I've taken note, again thank you.

0 Kudos
Message 6 of 9
(4,839 Views)

This is the hypothesis that I am working from these days: an actor is appropriate any time I need an asynchronous operation and need to communicate with that operation while it is working (especially if I may need to abort it mid-way through its work).

Obviously, synchronous tasks are just subVI calls.

Some asynch tasks can be kicked off with a simple Start Asynchronous Call By Reference, when I know that the task is going to run to completion.

It's the ongoing procedures that need to be actors, the things that will be sending me their results periodically, that I may need to interrupt temporarily, possibly abort, maybe reconfigure as they are working, or that need to coordinate their ongoing activities with other activities running in parallel.

You definitely shouldn't try to make an Actor Framework actor out of everything. But just like it is useful to think of every piece of data as an object even if you don't make every wire into a LabVIEW class, it is frequently useful during design to think of every routine as an actor and then formally make an Actor class only when it rises to that level of complexity.

At least, that's my current thinking on the matter. It is a position that has evolved over the last 7 years and continues to shift as I dig deeper into actor-oriented programming theories. Feel free to to dispute or coorberate.

0 Kudos
Message 7 of 9
(4,839 Views)

AristosQueue wrote:

This is the hypothesis that I am working from these days: an actor is appropriate any time I need an asynchronous operation and need to communicate with that operation while it is working (especially if I may need to abort it mid-way through its work).

Obviously, synchronous tasks are just subVI calls.

Some asynch tasks can be kicked off with a simple Start Asynchronous Call By Reference, when I know that the task is going to run to completion.

Because I created my instrument classes before switching to the Actor Framework, I was using Start Asynchronous Call By Reference in a few places and polling (ick!) with an immediate timeout on Wait On Asynchronous Call to get results. It's a low-memory solution, since I only need keep the reference, but I'm pretty sure the high-level polling eats CPU. (I actually didn't check, since I've seen it in other code.)

I briefly considered using a while loop with notifications (a kind of QMH) in my Actor Core VIs instead, but quickly realized it would be easier to maintain a sub-actor for the blocking tasks. I'm considering making a Blocking Task Actor class since I have a few instruments that need it. It would be nice if my colleagues didn't have to worry about these things once they start making their own instruments.

It's the ongoing procedures that need to be actors, the things that will be sending me their results periodically, that I may need to interrupt temporarily, possibly abort, maybe reconfigure as they are working, or that need to coordinate their ongoing activities with other activities running in parallel.

One thing I needed that others might need and not found in LV2014 is what I'm calling a "synchronization pool". If there's a better name for this, please let me know. I have an actor which receives data from its sub-actors, but does not pass that data on to other actors (e.g. for display and recording) until it has received data from all of its sub-actors. Each sub-actor's datum is held in a pool until the pool is full and then the data are sent synchronously to the other actors. (That's "synchronously" in the sense of simultaneity, not the messaging protocol.) The synchronization pool is a non-actor class object within the actor, not the actor itself. Unless there's an example already out there, I'll be sharing this with the group once I have a demonstration and documentation.

You definitely shouldn't try to make an Actor Framework actor out of everything. But just like it is useful to think of every piece of data as an object even if you don't make every wire into a LabVIEW class, it is frequently useful during design to think of every routine as an actor and then formally make an Actor class only when it rises to that level of complexity.

At least, that's my current thinking on the matter. It is a position that has evolved over the last 7 years and continues to shift as I dig deeper into actor-oriented programming theories. Feel free to to dispute or coorberate.

My synchronization pool class is something that shouldn't be an actor, in my opinion. If it were, then it would be receiving messages from its siblings and those siblings would have to reply to it rather than to their caller. I call the actor which makes use of the synchronization pools a "manager". It uses two pools: one for experimental data, and one for saving instrument configurations. I have considered making the pools into actors, but that would require a lot of communication between siblings and the manager actor would also have two very different classes of sub-actors.

0 Kudos
Message 8 of 9
(4,839 Views)

auspex wrote:


One thing I needed that others might need and not found in LV2014 is what I'm calling a "synchronization pool". If there's a better name for this, please let me know. I have an actor which receives data from its sub-actors, but does not pass that data on to other actors (e.g. for display and recording) until it has received data from all of its sub-actors. Each sub-actor's datum is held in a pool until the pool is full and then the data are sent synchronously to the other actors.

Sounds like an Aggregator.  My aggregator in Messenger Library, "Redeem Future Tokens Asynchronously", is also not an actor.

Message 9 of 9
(4,839 Views)