Following the restricted order of communication

[lewboi]

Hi all,

As we all know, to Minimize Communication Errors Between Actors, you can only talk to the caller or any nested actors.  This is taken from the documentation:

This restricted order of communication is called a task tree. It means there is only one communication path to manage, making it easy to write code that ensures that other actors have a chance to hear and respond messages before shutting down.

For example, this template defines the following task tree:

What I would like to know:

What do I do if Alpha needs to talk to Beta?  Should you sent to the caller who forwards it onto Beta? or sent it straight to Beta?

Is breaking the task tree common?

So far I have done one project using Actor and I managed to stick to the framework by having a loop doing some stuff in caller actor.  However,  I think it would have bean easier to put this in a separate actor but it would have meant me breaking the task tree.

Any thoughts?

Thanks

Lewis

[Oli_Wachno]

Hi Lewis,

I think, there are different opinions about this topic, I do prefer the hierachical way with message forwarding through the hierachy.

You can have actors communicating with each other aside the tree, but it's just like in the real-life: if you have multiple persons communicating in an unstructured manner, you can experience (let's say) funny effects you didn't expect.

But the world is not monochrome, the communication between Actors is neither. If you can make up a communication scheme, that's fullfills your requirements, especially regarding stability, go with it

Hope this gives you at least a little idea...

Cheers

Oli

[KuGr]

Hi Lewis.

I break the tree.  But my Actors are registered for a level of exposure/scope (Private, Protected and Global).  A Private Actor abides by the Actor Tree.  A Protected Actor can be shared with siblings (and their nested Actors). Global Actors can be shared with any Actor.  The Actor's Enqueuer is shared.  The caller Actor always retains the scope and enqueuer.  If the scope is Global, the callee's Enqueuer is shared up the tree (retained by each Actor) until the Root is identified.

I also do not like message forwarding.  To many repeated hops.  When an Actor wants to message another Actor that it does not know the Enqueuer, it requests the Enqueuer from it's caller.  That request continues up the tree until the enqueuer is found.  A message is sent back to the requesting Actor and cross-tree communications can occur.

My Global Actors are more like services.  They are responsible for supplying data values access (read and write) to multiple independent Actors.  So, I am not too concerned over a cyclic message path.

Also, the Callee will only accept a 'Stop' message from its Caller.  So no rogue Actor can shutdown another Actor.  All of my messages (derived from Message) contain the sending enqueuer.

All of my code is for internal use, so I can instruct my developers and control, somewhat, bad behavior.

Kurt

[justACS]

It is permissible for your top level actor to pass A's queue to B, and vice versa.  There is nothing wrong with that, and if our documentation says there is, it needs to be changed.

You should, however, have some specific reason for doing so.  "I like all my actors to be able to talk to each other" is not sufficient.  "I need central error logging" might be.  That's why the tree structure is the free default; if you have to do work so that A can talk directly to B, you won't do it arbitrarily.

[AristosQueue (NI)]

I follow the tree (meaning Alpha sends to root who sends to Beta) unless the number of messages becomes excessive and becomes a performance bottleneck. And before I break the tree (meaning root sends a message to Alpha containing Beta's Enqueuer and vice versa so they can talk together), I ask myself whether I really have my actors arranged correctly -- in other words, perhaps Beta be a nested actor of Alpha if they really are working that tightly together.

> There is nothing wrong with that, and if our documentation says there is, it needs to be changed.

Our docs say "minimize" not "never."

[AristosQueue (NI)]

Let's take this out of the hypothetical for a bit. What messages, specifically, are you sending from Alpha to Beta?

[lewboi]

Thanks for all of your input guys.  An interesting response, especially that everybody does it differently.

So I have an application that looks like this.  We have data coming from a network stream in a loop running along side actor core.  This then forwards all of the data to 3 screens and each screen pulls out the data relevant to itself.

What I don't like about this is my parrallel loop which I need to control from actor core (like shutdown commands) and its not that easy to re-use the code.

This is my loop alongside actor core:

The alternative which I thought about doing is this.  The cRIO actor is in charge of getting data from the cRIO and sending it to the 3 monitors.  This way the cRIO IO Actor is in charge of all of the comms and there is a nice defined messaging protocol between it and the caller (not like my string based queue like above).  I wanted to do it like this but didn't because it broke the communication tree.

Knowing what I know now,  I have made a variant of the Linked Network Actor and used that instead.  This would be a hybrid of 1 and 2.  The LNA would send data to the host and the host would forward it to the screens.

[AristosQueue (NI)]

Lewis_G wrote:

Knowing what I know now,  I have made a variant of the Linked Network Actor and used that instead.  This would be a hybrid of 1 and 2.  The LNA would send data to the host and the host would forward it to the screens.

That sounds like a viable approach. Let us know how it works out.

The other possibility is to have your main actor's Actor Core.vi set up a Time Delayed Msg (see the Advanced palette of the AF) that repeats every N milliseconds that says "poll the CRio incoming data". Then you would just handle it in there. Store the delayed msg's notifier in your actor object. In your Stop Core.vi, you would use the notifier to stop that repeating message.