How do you Identify Actors?

[drjdpowell]

komorbela wrote:

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?

AND it with a 32-bit number randomly generated and retained on first call.

Edit: I mean XOR it, not AND. 

Message was edited by: drjdpowell

[Daklu]

komorbela wrote:

What do you think about the options, is there a best way, would you do it otherways?

The "best" way is the simplest implementation that meets your needs.  Don't spend time and add complexity optimizing for search speed if that isn't a bottleneck in your application.  I always start with 1d array and refactor later if needed.

If you're concerned it will be too hard to change from a 1d array to something faster later on, create a collection object to encapsulate the implementation details.  Then you can change the implementation without affecting how the actors interact with the collection object.

[komorbela]

Thanks for the ideas, it was worth to ask The binary search idea I like very much, tomorrow I will give it a try!

The other is also good, but I don't want to rely on first call. That way I should request the user to include it in the main VI or Actor, or to set up a FGV. I was thinking about using the LabVIEW's version number or something that stays constant for sure until a LabVIEW program runs, but cannot be guaranteed to stay constant forever... just thoughts. And of course reading it has to be very fast. So no real idea yet.

Thanks again, will keep you updated about the results.

[komorbela]

So, after seeing and testing all the possibilities I came to the following: it is really impossible to find the "best" solution. I wanted to artificially speed up evolution, but it seems like I rather just have to wait. My brain and PC was not enough to simulate a bunch of LabVIEW developers working on several projects and coming to real good decision

I have created classes that hide the data type and implementation and could be changed later (something like Daklu suggests). I have an ActorID class with one member data which can be a U32, an Enqueuer class or anything that you like. It is beneficial if any set of it can be ordered, sorted. This class has comparison methods like "Equals", "Greater than", "Less than" comparing the actual object to another object of the same class. Than there is another class called ActorIDcollection which has an array of ActorIDs (and a corresponding array of IDs of the recipient Enqeuers) as the member data. It has public methods like "Add", "Del", "Search". The Add is sorted, the Search is binary (thx James) using only the comparison methods of the ActorID class.

This way I could reach good speeds using U32 or Enqueuer as Actor ID. The speed penalty compard to the non-encapsulated, raw implementations using U32 or Enqueuer arrays is about 16%. So making the ActorID very flexible has 84% speed compared to directly choosing a solution and hardcode it. I find it acceptable. (However I had to do it wisely to reach that speed: all methods have to be static dispatch and inlined into callers.)

[komorbela]

A possible source to use for "encrypting" the queue's refnum could be the "this Application" refnum. I have found that reading this value and XORing it with another U32 takes negligible time (can't recall now the average duration but less or about 1ns).

Based to what I know and what I have found (Obtain Queue, Queues across app instances) it seems like that a queue can be used only in one app instance where - obviously - the application instance refnum has to stay constant. This is the relevant line from the Obtain Queue's help:

"If you obtain a queue reference in one application instance, you cannot use that queue reference in another application instance. If you attempt to use a queue reference in another application instance, LabVIEW returns error 1491."

So what do you think about this solution to hide away the real refnum of the queue from the user, but still having a unique and constant identifier for a queue?

Does it conflict with any current features, properties of LabVIEW?

May it conflict with any future plans of LabVIEW?

[rik_aspinall]

Just a thought, but using a GUID instead of an integer might be nice. It's large enough that you shouldn't ever have to worry about a match. It can be generated independently of other actors. I think there's an open G library for generating them. Typically they're 128bit, see https://en.wikipedia.org/wiki/Globally_unique_identifier for more  info.

[AristosQueue (NI)]

Enqueuer objects are comparable using the comparison primitives.

You can also create a sorted array with Sort 1D Array.

All LV class objects are comparable, even heterogenous ones.

[AristosQueue (NI)]

Really, seriously, use the Enqueuer object as the unique ID. Seriously. There are all sorts of protections built into LV to avoid collisions, reuse, etc. They are comparable, searchable, serializable, etc.

You don't need GUIDs or any other magic.

[rik_aspinall]

Hi AQ,

One thing I'm concerned about doing it that way is a principle of trust. This is a lot of knowledge I don't yet know (maybe you can point me in the right direction) but

- If I can make an application with multiple developers working on different libraries

- If they can be loaded at runtime

- If I have two domains to the program, a controlling domain which is very controlling and structured for starting actors and passing queues to each other, that is a fixed framework, versus an application-based domain where multiple developers can develop within the framework

then...

it seems to me that passing the actual actor queue might be undesirable, since A can pass to B can pass to C, which means A and C are now directly talking, which I may not want (or at least without knowing about it in the formal, control domain controlled way).

(It might be especially true if I ever graduate to LNA's.)

perhaps you have thoughts on my scheme, (in a sense it must be what you went through making the AF in the first place!) and maybe alternatives to sharing the queue under these constraints.

Rik

[CaseyLamers1]

In almost all cases you want the communication to be a tree hierarchy.

One exception that I have made is sharing an error logger with the various pieces. Here I launch the logger at the top level and then pass it down when nested actors are launched.

Casey