From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Communicate Between Parallel Nested Actors

Solved!
Go to solution

Also, it's really important to notice that this isn't a Parent-to-Child relationship, it's a Caller-to-Nested relationship.

 

When building things with actors you typically only care to launch the actor classes at the bottom of your actor class hierarchy. These represent fully implemented functionality, parent actor types often have blank logic in virtual methods intended for overridden behavior further down the chain. When you launch an actors at the bottom of the class heirarchy it gets all the logic of that entire chain!

 

It's called Composition when actors launch nested actors, and it's a different axis of construction than parent-child relationships. The execution tree of the Root actor and all of it's requisite nested actors (and their nested actors), is a different tree than the class hierarchy!

Craig H. | CLA CTA CLED | Applications Engineer | NI Employee 2012-2023
Message 11 of 29
(3,066 Views)

@Taggart wrote:

 

 

So if you want to stick with the recommended way and need to communicate with a sibling, then you would need to send it to the parent who would then pass it on to the sibling.


What would one of these "forwarded" or "pass along" messages look like? I hear people saying that a lot of messages for an actor is around 15 or so...to facilitate this sort of architecture, how does one implement this functionality without having messages whose purpose is "send this message received from actor C to actor B" or something like that?

 

Message 12 of 29
(3,065 Views)

@Craig_ wrote:

 

If you want to send messages between non-related actors, all they need is the enqueuer for each other, but who facilitates giving this to them? Smiley Happy


Thanks for the food for thought...I feel like my code is a bunch of teenagers at a kegger now!

0 Kudos
Message 13 of 29
(3,064 Views)

@CanadaGuy wrote:

Pardon my ignorance, but can you clarify something for me?

 

Do I understand correctly that the hierarchical approach is one where you send/receive messages only between adjacent actors based on who launches who? Actor A launches actor B, and actor B launches actor C. A should communicate with C by sending a message through B. If A launches B and C, then B and C would communicate only through A?


The communication scheme in AF is designed for communication between Root Actor and Nested Actor (Read Caller Enqueuer) and Actor with itself (Read Self Enqueuer). AF follows the principle of secrecy. The enqueuer of a nested actor should only be known to the root actor. If You break the secrecy, a nested actor could shoot down another nested actor without knowledge of root.

The world is not always hierarchical. Sometimes giving up secrecy makes sense, but you should be aware of the consequences.

In your case, I would suggest the following structure: Define a root controller actor that starts other nested actors (UI, simulation, log) and manages communications due to AF standard. I guess the effort will be limited. At least that's my experience.

0 Kudos
Message 14 of 29
(3,062 Views)

@p4keal wrote:

The world is not always hierarchical. Sometimes giving up secrecy makes sense, but you should be aware of the consequences.

In your case, I would suggest the following structure: Define a root controller actor that starts other nested actors (UI, simulation, log) and manages communications due to AF standard. I guess the effort will be limited. At least that's my experience.


I was thinking I would make the log actor enqueuer global, in the sense that all nested actors would receive a copy of it and be able to write to the log as needed. Since the logger wouldn't do anything else, there should be little to no delay holding up the log actor from updating/writing the log to disk.

 

Now if I wanted to avoid that scenario, what would it look like for a calculation actor, launched by the simulation actor, wants to send a message to the log actor? From my pov, it looks like a message from calculation to simulation, a message from simulation to root, and a message from root to log...?

0 Kudos
Message 15 of 29
(3,049 Views)
The tree model is certainly recommended, but not enforced.

I agree, and this is how it should be. (Don't prevent users from violating best practices when they need to.) 

 

My question was with the statement that having sibling actors communicate directly was the recommended way to do it. I would recommend people new to actor oriented programming stick to hierarchical messaging until they have enough experience to understand the potential problems  of breaking that paradigm. 

0 Kudos
Message 16 of 29
(3,045 Views)

Perhaps the recommendation should be modified to include a few exceptions? I'm still very much a noob when it comes to AF, so tips, recommendations, etc. are things I cling to for life! 😛

0 Kudos
Message 17 of 29
(3,043 Views)

 

 

 From my pov, it looks like a message from calculation to simulation, a message from simulation to root, and a message from root to log...?

Yep, exactly. Furthermore, the calculation actor would be sending some sort of status message up the tree. It's the root actor that decides that needs to be logged to disk.

 

I was thinking I would make the log actor enqueuer global, in the sense that all nested actors would receive a copy of it and be able to write to the log as needed. Since the logger wouldn't do anything else, there should be little to no delay holding up the log actor from updating/writing the log to disk.

If you are writing your actors correctly, there should be little to no delay in the messages getting to the logging actor through the tree. 

 

Direct messaging (not following the 

tree) is possible, but it increases coupling and can have unexpected side effects. It depends on your application and what kind of message you're sending. Data messages are fairly safe to send directly. Control messages should always follow the tree.

0 Kudos
Message 18 of 29
(3,040 Views)

I see...I have been paying little to no attention to the purpose of a message (data or control), so it appears I need to start distinguishing between the two.

 

In the case of following the tree structure, I do understand how sharing enqueuers between various levels of actors would result in varying degrees of coupling. Earlier someone mentioned that the Evaporative Cooler example demonstrated the queue sharing (I think). Is there an example showing perhaps 2-3 nested levels of actors where the messaging is passed up and down the tree? I don't think I've seen one yet, and if I did, I didn't recognize it.

0 Kudos
Message 19 of 29
(3,035 Views)

 


@Craig_ wrote:

Also, it's really important to notice that this isn't a Parent-to-Child relationship, it's a Caller-to-Nested relationship.

 

 


You are correct.  Thanks for catching that.  I did mean Caller-Nested.
 

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 20 of 29
(3,031 Views)