Re-Entrancy with Shared Memory and Multiple Instances of one Actor

[Q7]

Say I have a ViewTest actor which is a GUI that views tests from a file. If I launch ViewTest 12 times do I get 12 independently running instances? How do I make sure each one sends a unique To-Self-Q back to the caller? If I am just adding each queue into an array, what do I do when one of the Viewers is closed?

[KuGr]

If I launch ViewTest 12 times do I get 12 independently running instances?

Yes, the Launch Actor launches a new Actor.vi.  Actor.vi creates and returns via a transfer queue, its SendQueue (the Send-To-Self queue wrapped as a SendQeue).

How do I make sure each one sends a unique To-Self-Q back to the caller?

I am not sure it can happen any other way.  Part of Actor.vi is to call Obtain Priority Queue.  This creates new unique queues.

If I am just adding each queue into an array, what do I do when one of the Viewers is closed?

Well, a Viewer can notify the caller via a message some how you will have to equate the messages reply queue with one of the queues in the array.  Alternately you can take a passive approach and remove the Viewer queue from the array when you try to send it a message and the send fails because of a an invalid queue reference.

I am not sure how this realtes to Re-Entrancy and Shared Memory.  I am not an expert on this, but my understanding is the the memory shared were the local scoped items like shif registers.  Actor Core.vi does not have Shared Memory - it better not as the Actor itself is one of the shift register.  The Message::Do.vi does have shared memory but this is up to the implementor od the Do.vi how use this feature.  My Do.vi methods, in general, are very simple as the call some handler build in the actor.

Hope this helps.

Kurt

[AristosQueue (NI)]

Each call to Launch Actor creates a completely independent -- no shared memory at all -- running actor.

Shared Reentrancy and Full Reentrancy behave identically in this case because the actors just keep running, so there's no chance of a VI being reused for another actor. If you stop an actor and then you launch another actor of the same or child type, you may get the same Actor Core.vi, which would mean that if you started adding state into your Actor Core.vi (uninitialized shift registers or local variables that you do not clear at start of run or full reentrant subVIs with the same) then you could start off with the same values you had before.

You don't know how many times in the last decade I've wished LabVIEW had a VI property for "break VI if includes any state data".

[Q7]

Got it, thank you. I keep forgetting the Actor is still running until the Core finishes.

AristosQueue wrote:

You don't know how many times in the last decade I've wished LabVIEW had a VI property for "break VI if includes any state data".

Yeah, that's caused me a few hiccups. It can really do a number on a PID loop!

[Q7]

Thanks Kurt, you're becoming an expert on the AF before it really hits the shelves. I'm trying to figure this thing out but it's killing my project deadline!

I was concerned about how to add the new Actor's queue to the array of similar Actor queues but a review of the Cooler demo helped me out there. I think I was looking for a way to identify each similar Actor without having an array of "ID" accompanying the queues but that's impossible.

Lastly: Hey NI Gods! It's hard to dive-in when you **know** the AF in 2012 is dissimilar. How about you release the 2012 library for 2011 (installing into the right place as well) so we can get some work done;) 

[KuGr]

I hope my post did not sound condescending.  I apologize it it came across that way.  Actually I am excited to see another user on the discussion board.  I have been using AF since shortly after it came out - some derivation of version 1.  In that version I actually played around with the core structures as I have an existing OOP hierarchy I wanted it to fit in.  When Version 2 was published at some point last year(?), I decided to take it as is and not make any changes.  The conversion from V1 to V2 was extremely painful for me.  V2 to V3 was not so bad.  I am not looking forward to V-2012.  Not sure I will actually head that way as I do not think the underlying framework is changing.

Just to let you know, you can still simply have an array of SendQueues and search for a match.  I do that.  My base Actor has a SendQueueList to keep track of its observers.  If an observer is no longer interested, it sends a message with its SendQueue to be removed. The subject actor does a Search 1D Array with the observers send queue sent in the message and then Delete From Array with the found index.  Works like a charm - well no complaints anyway.

I am not on the LV2012 Beta Club - I have no time to test this out and have no particular feature I want to see.

I hear you on deadline stuff.  I was fortunate that my customers (all internal) were patient.  I was the only developer using this framework.  Now I have one more and another (my manager) who wants to use it but is swamped in internal paperwork and rarely programs.  It can get very complex in a hurry and it did not happen overnite.  It is tuff to create something that supports broad use cases.  At some point I will post a sanitized version of my derived framework.  I have huge restrictions from my company on anything I do outside.  Regardless of the forum, I am still a representative of who I work for.

Keep posting your questions or comments!

[AristosQueue (NI)]

jbjorlie wrote:

Lastly: Hey NI Gods! It's hard to dive-in when you **know** the AF in 2012 is dissimilar. How about you release the 2012 library for 2011 (installing into the right place as well) so we can get some work done;) 

The version of AF now on the web will still work in 2012 and installs into a different location (user.lib) than the one that ships with LV (vi.lib) so applications written against the current AF will continue to work using the one in user.lib (assuming you add it to your LV 2012 install). There are no known bugs in the on-the-web version, so there's no pressing need to switch to AF 4.0... just some features that you'll wish you had. 🙂 But changing to the new AF should be straightforward -- delete your user.lib install, let LV search for the missing VIs (and find them in vi.lib) and then fix the relatively few compatibility bugs.

As for pre-releasing... you could join the beta program and then do some testing on the "Save For Previous" feature. Yes, this is me dangling a carrot in front of you to encourage more beta testing. 😉

[Q7]

KuGr: Not condescending at all, I hope I didn't sound upset! That reminds me of an email I sent my bosses (owners) once here that almost landed me out the door When I sent them the message it meant one thing but when they read it they read something different and it wasn't good. I'm pretty bad at setting the tome in my written messages I guess. Your messages have always been helpful and encouraging, thank you! I look forward to seeing some of your work if you ever get it de-classified. For me, I have a project waiting to ship Instrument #1 as soon as I get this package together and it's taking forever! I've had the itch to re-write our software from the ground up for a few years now and this was the time to do it if ever. Now I'm feeling the pressure...Not so easy being a one man software team but I am enjoying the education.

AQ is a whole nother story though...J/K Really, Stephen, the LAVA gang, and many others provide an enormous amount of help through these forums. Without them I would be in big trouble. NI has really hit a home-run with their employees and attention to real user needs/feedback. It is  absolutely fantastic to see "...Idea submitted by NI Foums member..." on the release notes. I hope they/you keep these goals high on the priority list. No better way to ensure success of a company.

Also, Stephen, I did join the beta and that "Save for Previous" idea is a good one I never thought to use in beta, thanks.