Actor Framework Discussions
How do you Identify Actors?
Hi guys,
First of all I have good news: I got the go to use and modify the Message Maker source, so I will be able to post it soon - a soon as I come to a version which is really a good candidate for further development.
I want to make the zero coupled message creation useful for all kinds of message mediators (the actor that receives the message from one actor and sends it to the final receiver actor. Let's call it controller from now on.)
There are methods for message transmission which needs to identify the sender actor. For example if you have many instances of the same sender actor, but only one instance of controller.
As a first implementation I included the Message Enqueuer class in the message sent by the sender actor. In the controller I stored the Message Enqueuers of the the launched classes in a mapping array which shows sender to receiver(s) mapping.
When a message arrives I search through the array of Message Enqueuer classes of the senders to find the match. It works but not efficient. I have made tests (You can have a look at my test vi in the attachments: "QueueClass.zip" Just change the array input wiring from one array to the other to compare.) and found that in case of only 100 queue classes I have 170000 match/sec. The same measurement for a 100 sized array of U32s is about 6000000 match/sec. It gets worse for more queues.
So I really would like to have a unique integer numeric ID for an actor. As the only thing we can access after launching an actor is the queue to it, the queue reference converted to number would perfectly do it. I have made my first try by adding one method to the Message Priority Queue class which converts the Priority queue to U32 Refnum:
Another method is added to Message Enqueuer class to pass the Refnum out to the "public world" to be able to use it:
This modification would need an action from AQ to modify the AF. I find it backwards compatible, so no problem, but it has to be the best method to really get into the AF.
How would you do it?
What do you use for identifying an Actor?
Is there a way to implement without modifying the classes of the AF?
I also attach the modified AF for making it all clear. Please don't forget to backup your original AF folder before overwriting it (if you will do so).
drjdpowell wrote:
komorbela wrote:
I hope to get the number from the end and convert it will also not last too long - it should not.
I don't understand this statement. The "Actor.vi" clone remains in operation until the actor shutsdown, so you can get its clone number at any point.
I only worried about get to the clone number in string and convert it to numeric. "lasts" meant time duration 
By the way I implemented the first test using Clone Number and it works fine. A get clone number (to numeric type (U32)) lasts about 2,5 ns.
to AQ: I still think getting the Queue's ref would be more powerful. What do you think?
So to summarize what I have in my mind now:
Identifying the Actor by it's Queue is the official way to go, in harmony with the Actor Model theory. It is the so called "mail address" to it, the only ID that we have, and need to have.
If actors can send messages with zero coupled messaging, it is advantageous if the message contains the sender actor's ID. All launched actors' IDs can be stored in a list and when receiving a message with the ID in it, we can simply look up ID in the list and identify the sender actor. There are different options to achieve it. I list the options below and include a test result for the speed of the look-up operation. For every case a list of 1000 IDs is tested. The result is in match/second, so how many times can we find a randomly chosen ID from the ID list in a second.
Options for actor identifying:
1) Use the Enqueuer object and "Search 1D Array":
-pro: easiest, straightforward, natural ID
-con: slowest search: 20 000 match/s
2) Use the Enqueuer object and Variant Attributes style lookup table:
-pro: easy, natural ID, close to optimal speed as ID list size grows over 20 000, but it's highly unlikely to ever handle more than 20 000 actors.
-con: slow search(at 1000 sized ID list): 110 000 match/s
3) Use the launched actor's Actor.vi's clone number as ID. Get it from call chain, convert to U32. Search with "Search 1D Array":
-pro: fastest 650 000 match/s
-con: not natural ID, this method uses an extra ID - unnecessary complexity, the clone number has to be sent by the already launched actor, so it has to be sent in a message.
4) The same as before but with Variant Attributes style lookup table:
-pro: as ID list grows, this will be the fastest
-con: not so fast for 1000 IDs: 270 000 match/s
5) Use the queue reference number (U32) extracted from the Enqueuer object:
-pro: as fast as using the "Actor clone number". It is also a U32 number, so no surprise. 650 000 match/s
-con: the Message Priority Queue class and the Message Enqueuer class of the Actor framework needs to be extended. The queue refnum is available to the user, but only as a U32 number.
6) Create one unique ID when creating the queue to the actor. Read this unique ID to identify the actors. this is only a rough idea, didn't try it yet
-pro:should be fast, queue to actor not exposed to any extent to the user, no need for a message to get the actor's ID.
-con: AF has to be modified, not natural ID, data size growth (but with very little amount). Not clear how to implement it exactly (to me right now )
So I have used the Enqueuer object, it works, but there are much faster methods. I still fin option 5) to be the easiest if
the user will not have access to the queue by only knowing the queue reference number.
The questions are:
What do you think about the options, is there a best way, would you do it otherways?
Can a queue be reconstructed from the U32 refnum without knowing the datatype? (I guess not, but I may not know about a trick that makes it possible...)
If the datatype is known (as it is known in case of AF) is it really a threat to AF queue safety?
To hide the RefNum away from the user an invertible transformation can be made on the U32 number. What should it be? Add a number to it? something more complicated?
Currently it is also possible to get the queue refnum for the Enqueuer object for example by using "Flatten to XML". It is only uncomfortable and unsafe, as it relies on an internal data strucutre of an object, that can change in the future.
How uncomfortable should it be for the user to get back the original queue, to confidently say that the queue safety of the Actor Framework is preserved? (for example a password protected VI which adds a constant to the U32 refnum and is not guaranteed to add the same number in the next version of LabVIEW...)
