What are best practices for asynchronously reading class properties of actors?

[auspex]

I needed a parent actor to get and set a few runtime properties of its child actors, so I used the Actor Framework Message Maker to create messages for the Read and Write methods of the child actor's class properties. I then modified the created Read message to be a subclass of Reply Msg, realizing that this was creating a synchronous method. I would ordinarily avoid the sync message, but it seemed acceptable at the time. It no longer is.

I see two options, and I don't like either very much at the moment. Actually, there's a third option of rethinking the design to eliminate the need for getters and setters, but I need to limp along the current path for right now.

Both options are for the child actor to provide abstract messages and the parent actor to provide the concrete implementation messages. They are:

1. Provide an abstract message for each property, and
2. Provide one abstract message for all the properties together.

Because these are reading properties on demand, the child actor also provides a "Request" message in which the parent actor provides its concrete implementation message object. I don't use the "Set Type Message" method because the concrete implementation may change and I need the on demand request anyway.

There are only a few properties and they are rarely accessed. The various subclasses of the child actor may add a couple of properties which the parent actor will need to read. Whether I choose option 1 or 2, I see no way around needing subclass-specific abstract messages. It seems those subclass-specific messages cannot just be subclasses of the base class message either. There's no way to just have subclasses of an abstract "Report Status Msg". I need separate abstract messages for "Report Base Status Msg", "Report Subclass A Status Msg", "Report Subclass B Status Msg", etc. Even if the abstract "Report Subclass N Status Msg" could be a subclass of "Report Base Status Msg", there would need to be a corresponding concrete implementation for each to make them useful.

Right now, I think the second option is better because it requires creating far fewer messages at the cost of larger messages; less work for me. At the moment it looks like five properties the parent might read from the child actor base class and maybe two to read from any child actor subclasses. The base class is an abstract class providing a hardware abstraction layer. The parent actor interaction with the child actors is mostly base class level. There's some interaction between the parent actor and the immediate subclass level of one of the child actors. Any deeper interaction is so far irrelevant to the parent actor.

Aside from the question of whether to have "Report Property A Msg", "Report Property B Msg", etc. or to combine them into "Report Status Msg", there's also a question of how to name things so it's clear what's going on. When I was using the synchronous reply messages, calling them "Read" messages was reasonable. That name no longer seems appropriate with the asynchronous getter. I have settled on "Request" in place of "Read", and "Report" for the abstract messages. The scheme looks like this.

Child Actor.lvlib

Abstract Messages for Caller

Report Status Msg.lvclass

Report Status Msg.ctl

Read Status.vi

Send Report Status Msg.vi

Messages for this Actor

Write Property A Msg.lvclass

Write Property A Msg.ctl

Do.vi

Send Write Property A.vi

Write Property B Msg.lvclass

Write Property B Msg.ctl

Do.vi

Send Write Property B.vi

Request Status Msg.lvclass

Request Status Msg.ctl

Do.vi

Send Request Status.vi

Frobnicate Msg.lvclass

Frobnicate Msg.ctl

Do.vi

Send Frobnicate.vi

Child Actor.lvclass

Child Actor.ctl

Property A

Read Property A.vi

Write Property A.vi

Property B

Read Property B.vi

Write Property B.vi

Report Status.vi

Frobnicate.vi

Parent Actor.lvlib

Abstract Message Implementations

Report Status Msg.lvclass

Report Status Msg.ctl

Do.vi

Parent Actor.lvclass

etc.

I've mostly followed the naming conventions in the available examples. One of these is that "Send . . ." for most message takes the form "Send Method Name.vi", but for the abstract message it takes the form "Send Method Name Msg.vi". It seems to serve as an extra reminder that the message is an abstract message. Still, a lot of this seems to be awkwardly named, perhaps because Read and Write in the properties has become Request, Report, and Write in the messages. The naming parallelism is lost there, and then also by the Request and Report being a combined read while the writes remain separate. Providing "Write Status" instead of the individual property writes would require either a mask or introduce problems keeping track of state.

Any better ideas for asynchronous reading of class properties of actors?

[drjdpowell]

auspex wrote:

I would ordinarily avoid the sync message, but it seemed acceptable at the time.

...

Any better ideas for asynchronous reading of class properties of actors?

I only skimmed your post, and couldn't really follow it, but have you considered asynchronous replies?  Have the caller actor attach it's own enqueuer to the request message, and in the "Do" of the request read the properties and then send a message back to the caller.  This would involve two message classes that would be part of "Parent Actor.lvlib" and you wouldn't add anything to "Child Actor.lvlib". 

[AristosQueue (NI)]

A variation on drjdpowell's post:

Don't have the caller try to read the properties of the actor. Instead, have the actor proactively publish its properties any time those properties change. The caller just keeps a cache of those properties and updates the cache whenever the actor sends it a new message.

I realize that this does not answer the question you asked. You asked, "How do I best do X?" and we answered, "Consider doing Y or Z instead." Give it some thought, and if you still want us to discuss how best to do X, let us know.

[auspex]

I thought asynchronous replies were what I was doing! But I had not considered doing it in the way you suggest.

I see I've had a mistaken idea in my thinking about actors. I was thinking of messages as something an actor must provide to make its own methods available to other actors. Since the parent actor no longer has direct access to the methods of the child actor after launching it, I was thinking of the child actor's messages as the parent actor's only way to access the child's methods.

So, this works and I think it looks much better than what I was doing. Thank you.

[auspex]

AristosQueue wrote:

A variation on drjdpowell's post:

Don't have the caller try to read the properties of the actor. Instead, have the actor proactively publish its properties any time those properties change. The caller just keeps a cache of those properties and updates the cache whenever the actor sends it a new message.

I realize that this does not answer the question you asked. You asked, "How do I best do X?" and we answered, "Consider doing Y or Z instead." Give it some thought, and if you still want us to discuss how best to do X, let us know.

I hadn't considered the way drjdpowell suggested because I didn't think messages and actors worked that way. I think it is "the way" to do X.

I do use proactive publishing in other parts of the program, but I was considering this for information I didn't want to cache or even receive most of the time.

[AristosQueue (NI)]

It sounds like you know what you're doing. Sounds like, from your other post, that you've got a viable solution now.

As I have said before: For many how-to questions, the helpful answer for a novice "don't", but the helpful answer for an expert is "carefully." 🙂

[drjdpowell]

auspex wrote:

I see I've had a mistaken idea in my thinking about actors. I was thinking of messages as something an actor must provide to make its own methods available to other actors. Since the parent actor no longer has direct access to the methods of the child actor after launching it, I was thinking of the child actor's messages as the parent actor's only way to access the child's methods.

Yes, with the "Command Pattern", that the AF uses, one can think of the commands as belonging more naturally to the Caller's codebase, with the Callee actor being just it's methods.