Access to internal actor data from its own actor core loop.

[p4keal]

If I follow recommendations from the post: https://decibel.ni.com/content/message/55585#55585, I feel programming a lot of code if I need access to internal actor data from its own Actor Core loop. So I have tried to develop two easy procedures in reason to get a snapshots from own actor data. Because I don’t have great praxis experience with Actor Framework I would like to ask AF community about possible pitfalls.

The library “Read Actor State Utility.lvlib” consists of two classes “Return Internal State Msg” inherited from AF “Message” and “Reply own state” inherited from AF “Repy Msg”.

I describe them using AF template project.

The idea behind “Return Internal State Msg”, each actor of interest must provide a single element queue with an Actor object as element. “Return Internal State Msg:Do.vi” calls “Return Actor Data”:

If I need a snapshot of actor data in my actor loop, I send “Return Internal State Msg” and wait for an element in the internal state queue, see “Get Actor Snapshot” below. In reason to use this class in my actor loop I have to do some preparations:

1. Add a Queue ref with an Actor.lvclass object to Alpha data cluster
2. Initialize the queue in “Pre Launch Init.vi” and clean up in “Stop Core.vi”
3. For convenience, create a member VI: “Get Actor Snapshot". The code should be the same for all actors expect Actor control and indicator. One can add a copy of this VI to own Actor library and replace “Alpha in/out” with own actor.
4. I call “Get Actor Snapshot” in Actor Core loop if I need a snapshot of my actor data.

The idea behind class “Reply own state” is to let send actor a reply message to itself. The usage don’t need changes on actor class and should be universal for all actors. In reason to get actor snapshot in actor core loop one has to call “Send reply actor state.vi”

“Do Core.vi” converts the actor to a variant:

“Send reply actor state.vi” waits for response and converts variant to actor:

One has to keep in mind that Actor Core loop and Actor State machine runs asynchronous and actor data may be changed during operations inside actor core loop.

[AristosQueue (NI)]

The goal of exposing the complete internal state of the actor to the other actor loops is generally an anti-goal. It generally indicates a problem with your design, usually something to do with getting into an inconsistent state.

If your parallel Actor Core loops need information from the actor data, then one of two things should happen:

a) the parallel loop should send a message asking for only the subset of the data that it needs

b) the actor message loop should be pushing that information out to the parallel loop (through a queue, event, etc) when that data changes so that the parallel loop already has the info on hand when it is needed.

But in general it is best to have that data contained in the message loop EXCLUSIVELY and have the message loops sending directives out about reactions to the data change. But sending the full state of the actor is usually a problem.

[p4keal]

Thanks for Your reply

Of course, exposing the state of a actor to the other actor is an anti-gool. But this is not my intension. In a LVOOP class a member VIs can access class data very simple via bundle and unbundle nodes. An "Child Actor:Actor Core.vi" is a member VI from "Child Actor" class. So I don't realy see the problem about data privacy. After all changes of internal data are only posible via message loop, I fully agree with that. But a simple read access is linked with additonal code. Usage of "Reply own state.lvclass" reduces this overhead, because it should be unversall for all actor children and none changes on actor child class are needed.

If one don't like the idea to send the complete actor, it should be posible to modify "Reply own state.lvclass" to send a subset of actors data.

[AristosQueue (NI)]

Yes, I got what your goal was.

And I'm saying it is an anti-goal even to expose the state even to other methods within that same class.

The correct use of the actor class means that the actual data of the class is not used by other methods while it is in the message handling loop.

> But a simple read access is linked with additonal code.

In the 90% case (my observation), the desire for simple read access is a sign of a bug somewhere OR the additional code is necessary for code correctness.

I'm trying to wave you off of this whole concept. 🙂

[p4keal]

Hello AristosQueue,

I think, I understand now Your point of view. A parallel loop in a actor core should be used only for user interface interactions. UI elements should be updated from actor message handling loop, this keeps actor data and UI view consistent. Thank You for food for thought!

[AristosQueue (NI)]

Not just for UI... it can also be for ongoing processes, like reading DAQ channels and other purely programmatic operations. But it needs to be administered by the the main msg handling loop, not trying to be co-equal with it.

Now, all of that is my experience... feel free to argue the opposite... your experience may vary. 🙂