System Architecture

[JIV]

I have a system architecture question regarding the actor framework.  I'm making a protocol analyzer which makes uses of a profile to store things like the channel configuration, number of channels, etc.  In the past, I built this as a functional global with all sorts of get and set cases.  All through out my code, different pieces would call this global with the get profile case and retrieve the profile to perform some actions.  My questions are the following:

1) I want to implement this profile manager as an actor.  In other programming languages, this would be a good use of a singleton which I've read some articles about doing such in Labview.  I was wondering if it would be a good idea for the launch actor vi to be made in such a way that you can pass it a name and if that actor class with that name already exists it would return the queues of the actor instead of launching one.  In iOS objective C there are such things like [NSNotificationCenter defaultCenter].

2) This actor that contains the profile needs to be accessed by other actors, is this okay to be done through reply messages.  As much as I'm trying to avoid them, I don't see another good way of retrieving data from an actor?

Just looking for some thoughts on the subject.

Thanks in advanced for your time.

JIV

[David_Staab]

JIV wrote:

1) I want to implement this profile manager as an actor.  In other programming languages, this would be a good use of a singleton which I've read some articles about doing such in Labview.  I was wondering if it would be a good idea for the launch actor vi to be made in such a way that you can pass it a name and if that actor class with that name already exists it would return the queues of the actor instead of launching one.

Just yesterday I thought I had a need for a Singleton Actor, too. What you want, instead, is another Actor that holds addresses for your single-instance actors and receives a message to "Obtain Actor". The message can look for a queue to the desired Actor and, if none exists, launch it and store the queue for future dispatch.

Of course, that requires using strings or some other unique identifier to reference an Actor and get its queue. I personally dislike referencing objects by name in my designs, so insatead I scrapped the whole idea and rewrote my actor-caller to launch once and retain the Send Queue refnum for later use in its recurring logic.

(Something I just thought of: You could make a unique message for each actor you want to obtain. That would be a unique identifier, although it would be a little overkill...)

[Wart]

2) This actor that contains the profile needs to be accessed by other actors, is this okay to be done through reply messages.  As much as I'm trying to avoid them, I don't see another good way of retrieving data from an actor?

I think it's worse, but you could pass a reference to the To-Actor queue for your handler actor to each of your other actors when you create it.  Then they have a way to send it messages.

The only time I've used the actor framework (which was mainly to learn a bit about it, rather than write production code) I did something like that.  I had a AI DAQ actor that I set up to just sample all the channels I might ever need.  Then when I created an actor that needed the analog input data I stored a reference to the To Actor Queue in that classes data.  It then sent a message to the DAQ actor with a refernce to its to queue and the AI channels it wanted back.  The DAQ actor then sends the data back using the reference to the other actors to queue.  When the actor using the AI data is done is sends a message to the DAQ actor to "unregister" those channels and the DAQ actor quits sending it data.

It was a pretty good experiement in using Actors, though like I said, I think sharing the queues in that manner is frowned upon.

I really want to make a nice public DAQ Actor.. and call it, DAQtor !  Maybe once 2012 comes out..

[AristosQueue (NI)]

Let's say that you have one actor that is the top level actor of your application. All actors are launched by this top level actor. (If your toplevel launcher isn't itself an actor, that's ok... it's still the thing that calls Launch Actor and is capable of listening to messages from the other actors, so for the purposes of this conversation, it's an actor.) Let's call this actor "App."

App is going to launch Singleton.

Now something happens later and App decides to launch Other Actor. And then, after calling Launch Actor, App sends a message to Singleton that says, "There's a new actor who needs to hear from you." Let's call this the NewActor message.

You then have two choices depending upon how independent you want Singleton to be from the rest of the system:

1. App includes the Other Actor's queue in the NewActor message. Singleton hears that message and creates a new message that says "Here's the information you need" and enqueues it into Other Actor's queue. You can have Singleton remember the Other Actor's queue if you want it to be able to send further messages.
2. App does NOT include anything in the NewActor message. Singleton hears that message and creates a new message  that says "Please give this data to the new actor" and sends that message up to App. App hears that message and says, "Oh, in my private state data, I have a list of the new actors, so I'll take the first actor off that list and enqueue this data to him in a new message."

[AristosQueue (NI)]

> 2) This actor that contains the profile needs to be accessed by other actors, is this

> okay to be done through reply messages.  As much as I'm trying to avoid them, I

> don't see another good way of retrieving data from an actor?

Don't pull data from an actor. Have the actor *push* data out. If the state of an actor changes and its caller or nested actors need to know about that change, the actor can tell them about that change when it happens. It's a different programming model than most LabVIEW programs have historically used, but it appears to work much better overall.

[JIV]

Aristos,

I understand the pushing vs polling idea, and I do implement that through out most of my code.  However, when you have an actor that has state data such as a profile or a configuration file, that many actors need to use, if you only want to respond to the change, then you have to keep a copy in each actor of the latest copy that gets sent along with the message that the information changed.  Is this really the best way? 

I looked at the example of the angry birds from NI Week and the debug console was done in a way that could have benefited from a singleton, otherwise you need to create a functional global for the send queue of each actor that is sent messges by many.  I just don't see it as a very efficient way, to keep state data in each actor for each actor that you want to communicate with.

I'm not critizing, I'm sure that what you are proposing is a good way, i just do quite a bit of iOS programming and they handle communications between objects in a more diverse manner, with singletons and notification centers and property observers.

I will keep trying to maintain a pushing arquitecture as much as possible.

Thanks.

[AristosQueue (NI)]

Before anything else: DO feel free to criticize. 🙂 Everything I've put forth in the Actor Framework is backed by theory and some empiric testing, but it is by no means exhaustive for all use cases.

JIV wrote:

then you have to keep a copy in each actor of the latest copy that gets sent along with the message that the information changed.  Is this really the best way? 

It certainly appears to be, although it should be less common than you might expect.

In what I'll call a traditional LabVIEW program, you might have a central data repository that manages configuration options and many modules call in to read those options. The central repo is responsible for loading and saving the config file. But in this setup, how many modules need *every* value in the configuration file?

One of the design goals of an AF program should be to give an actor only the information that actor needs. You can achieve this by having your App actor hold the entire configuration and, as it launches each subsidiary actor, it gives that actor the portion of the configuration that that actor needs to do its job. During the run of the program, that subsidiary actor is in charge of updating the value of the configuration. At intervals, it may send a message back to the App actor to say "here, update this portion of your records so that when you save the full config to a file, it includes my latest changes." At no point do you replicate the *entire* database.

An alternate approach is to have a central actor that has the entire config. Other actors send it messages that say "I am in need the following bits and pieces". But this is *NOT* a Reply Message. It is simply an announcement of the actor's need. The actor has some private data variable that says, "I do not yet have the info to act on certain messages". The actor then goes on handling other messages in its queue and doing whatever else it has to do. This is a key idea: instead of waiting for a reply, the actor has other work to be doing... even if that work is just "wait for any other message." The most significant message that might arrive in the interim is Stop. How many times have you had a program that just won't shutdown quickly because some module is waiting for a response and so it cannot check for a shutdown instruction? With actors, you can avoid that. The actor announces its need and then waits for more messages. Eventually, the repository actor will send a message that says "here's the config info you requested". At that point, the actor updates its internal state to say, "I now have the info I need to handle more requests." If you wanted, you might even have saved up in your private state data all the messages that came in while you were without data and then immediately handle them as a block (either by calling Do.vi directly or resending them, maybe as a high priority Batch Message).

I have not myself built all of the above variations, but I've built enough of the pieces and have worked out enough theory  to say with some certainty, "This is a good way to construct these programs." Are there better ways? Maybe.

JIV wrote:

I'm not critizing, I'm sure that what you are proposing is a good way, i just do quite a bit of iOS programming and they handle communications between objects in a more diverse manner, with singletons and notification centers and property observers.

And that diverse communications manner is totally approriate *within* an actor. The procedural programming style and the "generally sequential events firing communication among a set of objects" pattern are useful within a module. An actor is working to achieve some effect, and that work may be best expressed in one of these other styles, such as an actor who manages a user interface relying heavily on events firing. A UI, even as "parallel" as it feels, is very much a sequential system of event-happens-UI-redraws. As such, even when it is expressed as parallel operations, it generally avoids the pitfalls of real parallel programs.

The actors are there to serve the case when two modules are working on different tasks, each with its own agenda.  My goal has been to standardize the major architecture units for parallel operations in a way that maximizes their utility and minimizes their probability of task collision.

As always, these are guidelines. Your application may work better by violating one or more of them. It's like your 6th grade English teacher told you: Learn to write complete, grammatically correct sentences. For such knowledge a better poet makes. 😉