Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

AF: send response to many actors; share actor's address; lock actor from message processing

Dear NI community,

I'm quite new to Actor Framework, so let me ask some questions regarding it.

 

I have some actor A, which should send some data (let's say, some configuration parameters) to other actors B, C, D, etc. - those actors can be many. All those actors have common patern (on different level), actor A is not within their hierarchy.

Now, come up 3 tasks.

1. How actor A should now, where it should send data? Actors B, C, D, etc. can have reference to actor A, and send messages with some data. And actor A should send back response to requester. Is it good approach to send with message data also reference of the actor (enqueuer address) - and then, when actor A will receive this message and process it, it can send message back by this reference?
2. Actors B, C, D, etc. should send data to actor A. I see 2 alternatives. The first one, is to inject reference of actor A to private data of actors B, C, D, etc., and then to use this reference to send messages to actor A. But, this gives more overhead, b/c initialization of this reference should be done for each of actor.
The second approach could be to save actor's A reference to some global variable (FGV), and then to use this reference to send messages to actor A. Could it be used like this?
The third approach is to have inside of actor A helper loop, where will be named queue. This queue will receive messages for an actor, and route it to itself (be self enqueuer). But, in this case, for each of command I need to create API VIs, which will incapsulate data of messages to be sent. What is done by AF itself, by Send... method for messages.
3. Before actors B, C, D, etc. would receive response from actor A, they should not process other messages, what could be sent to them. They can receive those messages, but as actors do not have configuration data, they can't process messages correctly. How to "lock" actors B, C, D, etc. from messages processing? What is the best and easiest approach? I guess, that using State Pattern would be overhead in this case? How to solve then it nicely, please?

Thanks a lot in advance!

 

Sincerely, kosist90

 

logos_middle.jpg

 

0 Kudos
Message 1 of 4
(3,083 Views)

Hi Kosist,

 

As you've probably already seen from Piotr's ESA code, you can store a variant in A and store enqueuers received by message as variant attributes. This is useful both when you want to send a message to all in a set (For loop with Get All Variant Attributes) and for specific targets if you know the name - for example in one of my parts of code I have radio buttons linked to actors in a subpanel and I store their enqueuers based on the flattened to string value of the radio button.

 

Regarding point 2, you can have A send a message in response (not necessarily a Reply message) when it receives the registration, possibly with high priority.

 

For point 3, I don't have a very good solution but you can send the message for registration in Pre launch init and then have some delay during launch. This is bad, because it will hold up all actors launching, but possible. If the reply is sent before the Actor starts, with high priority, it should be the first message handled (you can also place the delay in actor core before the call parent node - it is probably much better there). No messages are handled until the root level Actor (I mean by inheritance, not root as in Launch Root Actor) is called by the sets of call parent node in Actor core.


GCentral
Message 2 of 4
(3,009 Views)

Thank you, cbutcher, for your reply!

 

Regarding 2nd point - I mean when actors B, C, D, etc. send message to actor A, not vice versa. So the question is, how to get reference to A?

1. Keep it in private data of all actors, and pass it value then by chain to nested actors, etc.

2. Put it to some FGV, and then retrieve in any actor, if needed (b/c I implement it in the way, that actor A will be launched before any other, and will be closed as the last one, so reference to it in FGV will be alive all the time).

 

Regarding 1st point - yes, I do it in this way already, I've played with it a bit, and it seems to be working. I send to actor A message together with enqueuer reference, and when message is processed, reply is sent to requester actor. And indeed, requester actor does not wait for message, b/c it's not reply message, but some zero-coupled message.

 

3rd point - I guess, that this would not help me in this case, b/c receiving of config data is done also as messages - thus, it must happen just in Actor Core.vi. The only what I can do, is to send request in pre-launch init, I guess...

0 Kudos
Message 3 of 4
(3,005 Views)

@kosist90 wrote:

Thank you, cbutcher, for your reply!

 

Regarding 2nd point - I mean when actors B, C, D, etc. send message to actor A, not vice versa. So the question is, how to get reference to A?

1. Keep it in private data of all actors, and pass it value then by chain to nested actors, etc.

2. Put it to some FGV, and then retrieve in any actor, if needed (b/c I implement it in the way, that actor A will be launched before any other, and will be closed as the last one, so reference to it in FGV will be alive all the time).

 


Yes - I see the problem. My logic was quite circular because I thought at least one had a queue to the other, so they could use that. But your problem appears to be that neither knows the other Actor's enqueuer before at least one of them sends a message containing their own. You could consider passing a Self Addressed Message (from A) down if A the a root actor compared to B,C,D, or from B,C,D up via the Caller Enqueuer, but intermediate steps would need to pass the message along which might be as bad if not worse than just passing the Enqueuer down/up directly.

 

Regarding your 3rd point reply - yes, I see, but if you delay the wire before it gets to the Call Parent Node, until the message has been sent by A containing the config data with High priority, so long as it is the first High priority message sent (I don't know if you use lots of High Priority messages or not) it will be the first handled, so long as it is in the queue before you get to the Call Parent Node (which is where the messages start to be handled, as you already said).

 

An alternative possibility might be to have a boolean in private data of B,C,D etc which has a purpose like 'Configured?', and when you receive a message, if it is not 'Configuration Msg' and 'Configured?' is false, then drop the message by not passing it to the Call Parent Node of Receive Message.vi.


GCentral
0 Kudos
Message 4 of 4
(2,996 Views)