Object owner problem

[DanielSchick]

Dear all,

I've been using G# for a long time now without having any trouble, why I want to say thank you again for this great framework!

But today I was trying to change my application in the following way:

I have a few labview programs controlling different hardware elements independently. All of these programms use G# objects. In order to be able to communicate between these apps I use user events, e.g. to send a Global Exit event to all of the programs from within one of them.

As you might have guessed, there is no hierachy for these programs, so I start and stop them on demand without any main application in the background. The user events are handled by a unique G# object as well which is initialized as a singleton, so all applications can access the same user events, what works really nice.

Now the point is, that when I stop the owner of this user event object (the first started program), also the user event object is destroyed, although there are still 5 other programs running, which where also users of this user event object. As I figured it out, the first program that was started is the owner of the G# user event object and has to be closed at the end, in order to avoid any errors.

A similar situation occurs whithin the G# Debugger, which shows no initialzied objects at all if the first started program is closed, although all other programs are still ok.

So my question is, if the destruction of an object (singleton) is definetly linked to the owning program, or if the ownership can be inherted by other Labview programs that are still running?

If its not possible I have to use a main application as a wrapper, which takes care of handling the ownership, but it would be nice to live without it.

Cheers,

Daniel

[Mattias_Ericsson]

Hi Daniel,

We are very pleased that you like G#.  This is a very intresting topic, the ownership of objects. This is especially intresting, since the lifetime of a DVR reference, queues etc. is depending of the lifetime of the top-level VI that creates them (this is the way LabVIEW works and nothing we can do anything about). You actually see this owner information in the G#Debugger from the "Owner" field in the "Objects" tab. If the objects (actually the DVRs and queues) has been garbage collected by LabVIEW, they will not be shown in G#Debugger, since they are dead.

G# actually have a mechanism adressed to deal with exactly this issue, and it is called the "External Create Process". This is a background process that you start with the utility VI called "G#Object_StartExternalCreateProcess.vi". It is located in the G# menu ->Advanced->Start External Create Process. This process will create and own all G# objects and prevent LabVIEW garbage collector to clear them. It is stopped when running the garbage collector. This is useful if having multiple top-level applications, but is not needed with a single top-level application. In each of your top-level VIs place this VI as the first VI. If the external create process is already running, nothing will actually happen. You stop the process, either by running the garbage collector or the "Stop External Process" (this is not on the menu, but located in G#Object->Utils). You need to be a bit careful when and who that closes the external create process.

How does this actually work? When an object is created (and thereby all DVRs in the class hierarchy and also the object queue carrying object information), G# will sense if the external create process is running. It will then delegate the creating of the object to the external create process, so that this VI will own the object instead. The code is not locked, so go a head and have a look how it is implemented! Hence, you will not notice anything in your code! In the G#Debugger, you can now see that all your objects are not own by the top-level VIs, but by the external create process, and they will be alive as long as the external create process is alive. There is actually a green LED in the G#Debugger indicating if the create process is running or not. You can actually click on the LED to turn on and off the external create process in order just to test (without the need putting the G#Object_StartExternalCreateProcess.vi in your top level VI).

At AddQ we use this feature a lot, addressing just the problem you describe with LabVIEW top-level ownership that triggers LabVIEWs internal garbage collector. This is the reason the external create process actually exists, just because of this. I know that this could be a little bit better documented and also some examples. I will see what I can include in future releases to improve this.

Hope this help and that I understood you problem correctly.

Thanks,

Mattias

[Olivier-JOURDAN]

Hello Mattias, That's a great feature. Thanks to share it.

As Daniel said, G# is a really great framework.

Have a good day,

Olivier

[DanielSchick]

Dear Mattias,

I just tried the start_external_create_process.vi in my programs and the debugger now shows this process as the owner of all my objects. Unfortunately, I have added the Garbage Collector at the end of all my applications. So when I exit one of the programs still all objects are destroyed in the G# Debugger and I still recieve the same error message as without the extCreateProcess.

I guess I could avoid using the Garbage Collector and destroy all objects by their specific destroy method at the end, but the Garabge collector is much more handy.

I think I also have to call the GC once to also kill the extCreateProcess, right? So how do you handle this? In which program this is done, if you have no real top level VI?

Or is there a way to tell the GC not to kill the extCreateProcess if there are still objects alive in some applications?

I also think I found a bug within the user counter. If I do not use the extCreateProcess and create a Singleton object program A and then in program B the user counter is set to 2 and the owner of the Singleton is A. If I close now B and run the GC at the end the user counter in the Debugger is still 2. If I restart B now, the uc is set to 3 and so on. I guess it shouldn't do that...

Daniel

[Mattias_Ericsson]

Hi Daniel,

Yes, this is the difficult question. We had a lot of internal discussions how this should work if the garbage collector will kill the process always or not, but we ended up with this behaviour. So, your analysis is correct. I would recommend you to one of the following solutions:

1) Create a singleton class (or a static class) that you only use for synchronization. Let each top-level VI register to this class (by some kind of string array holding the names of the top-level VIs in the static attributes), when the top-level VI stops, unregister from the list and if you are the last top-level VI that exits, then you run the garbage collector. Make sure you set the boolean input "only from same owner as caller? (T)" to FALSE.

2) You could always use "G#Object_GetAllObjectsFromSameOwner.vi" to browse all objects and then loop the destructor manually, however, you loose the order of destruction (we discussed this before on the community). Then you could check if there is any other objects belonging to other owners (G#Object_GetAllObjects if size >0), if no other objects, stop extranal create process (could then use garbage collector).

I would have used 1). Most of my application would have a master application, and rest of the top-level VIs are "slaves", so if you have this situation the master would have the garbage collector, but I believe this is not the case for your situation.

No, there is no way to avoid garbage collector to avoid killing external create process. The main reason for this is the risk that external create process is still running after all VIs been closed even after running GC, causing LabVIEW to appear "hanging". The only way you can avoid it is if you specify a class name to the garbage collector, but then you have to loop all classes and run GC multiple times for each class.

Hope this help!

Mattias

[griffindore]

Hi Mattias,

As far as number 1 is concerned, has there been any thought into making the ExternalCreateProcess itself the singleton. Each top-level VI could register to the class by calling "Start External Create Process" and unregister by calling "Stop External Create Process". Seems like the "Stop External Create Process" could even be the one to call the garbage collector if all top levels have been unregistered.

Regards,

Mike

[Mattias_Ericsson]

Hi Mike,

Hmm, this is a really, really interesting idea.I think a can implement this really easy. Just have to check what side effects it might have (if any). Two thinks I see directly that I must consider is: 1) What happens if a registered VI "dies", stops without unregister and 2) G#Debugger uses the external create process, for the active debugging features (thats actually how objects could be kept alive here) and external create process can also be forced start and stoped here as well. But these things could probably be handled quite easy.

Let me think about it for a while, and I will get back soon this afternoon with a beta solution. I hope you don't mind if I credit you in the code comments?

My next G# release was planned this spring after I tried G# on LabVIEW 2012 beta (starts in jan/feb), NI always change some details forcin us toolkits developer to do minor adjustments, but if this end well, I can make an extra release earlier.

Keep up the good work!

Mattias

[Mattias_Ericsson]

Hi,

I've now got a beta version of G# 1.4.0 (note there are different versions of the IDE/Framework and actual G# code). I've implemented a registration in the StartExternalCreateProcess and unregister in the StopExternalCreateProcess. If a top-level Vi suddenly dies, it will automatically unregister when someone tries to stop or garbage collect.

Please copy the attached code and replace all existing files in:

<LabVIEW>\vi.lib\addons\_AddQ

Note, the code is in LabVIEW 2009 (since we still develope G# in LV2009). It should now work with Daniels orginal code if he only puts the StartExternalCreateProcess as the first VI in all his top level application and uses GC at the end.

Please let me know how it all works out. I need to run a few more tests to make sure that it work alright, but my initial tests ran just fine. If it seems to work just fine, I include it in the next release of G# Framework.

Thanks to you all for helping G# getting better!

Mattias

[griffindore]

Hi Mattias,

I certainly don't mind being mentioned in comments, but I'm not sure I deserve that much credit. Nice work in getting a beta version of that up so fast.

Regards,

Mike