08-07-2015 07:56 AM
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:
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.
08-07-2015 08:55 AM
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.
08-07-2015 10:32 AM
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.
08-07-2015 11:23 AM
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. 🙂
08-08-2015 03:59 PM
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!
08-10-2015 10:41 AM
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. 🙂