Memory & Thread Management

[Been bitten by LabVIEW]

This is not so much of a question but an article of stuff I've learned while working with LabVIEW 7.0.  If it doesn't belong here, let me know and I'll put it in the appropriate place.

Memory/Thread Management in LabVIEW^TM 7.0

Managing threads and other objects can be interesting in LabVIEW since it is all done by its garbage collector.  This can be an awesome help, but can also cause unexpected problems.  However, if you understand what is happening, you may be able to stop the most trivial of these and at least understand the more complex.

First off, all that follows is through observation.  I have not looked at the underlying mechanisms controlling this management.  If I am incorrect in any way or if there are changes in other versions of LabVIEW, please feel free to send me feedback on this article.

Now with that out of the way, here is how I have conceptualised the management of threads and memory.  Base types (numbers, strings, and arrays) seem to be exempt from what follows; their ownership is passed along to the threads they are passed to.

You can think of threads something like a garden.  You have your patch of soil (your thread space) and then you plant your objects (queues, user events, open refnums, etc...).  Then when the thread dies, everything that is planted in this patch of dirt is overturned and recycled back into the resource space by the garbage collector.  In simple applications, this isn’t a problem because this stuff is allocated by the main controlling thread, and if that dies, your application is probably done anyway.  If, however, you have threads creating threads and objects to be passed around the system, this can create a debugging nightmare, leaving you wondering, “Where did my ... go?”

The first time this really surprised me was when I tried to spawn a thread.  I opened the VI refnum, ran it and then immediately closed it.  What happened to my thread?  I tried to open the Front Panel to see why it aborted and I noticed that it would go along its merry way with no problem as long as it was open.  However if I closed the Front Panel inside its own thread, it would abort again.  What was going on? 

Well, it turns out that threads (VIs with an execution state of “Run top level”) are bound by the number of open VI refnums.  If you open the Front Panel, there is an implicit open VI refnum.  As soon as you close the Front Panel, that refnum is destroyed and so is the thread.  Ok, so I kept the refnum open from the spawner and then the spawner finished, this caused something else that seems so obvious now, it aborted my spawned thread! Of course it did, since the open VI refnum was planted in the spawner’s patch of earth, the refnum got turned back into it along with everything else.  Since there were no other open refnums, thread aborted.  Mind you, at the time, I really didn’t know what was going on, and all of this was quite confusing and frustrating. 😞

However, now that I know this, I can make much more reliable and reusable code, that spawns threads which don’t die unexpectedly with objects not disappearing into the void.  Here are some tricks to avoid these scenarios:

1.     Wait for you threads to finish

Yeah, sound easy and it can be.  One way is to keep track of all the VI refnums you have opened in the thread by sticking them into an array and at the end of the execution of your thread, wait on them to terminate.

This can be done by having a store VI refnums that tracks the refnums created by the current thread, and then as the LAST THING that thread does is to wait for the VIs associated with these on this thread to terminate IFF THERE ARE NO OTHER REFNUMS OPEN ON THE SAME VI.  If the VIs don’t terminate within some expected period of time, popup a message saying that these VIs are still active as threads, is it ok to abort them?  It also may be useful to allow them to be opened if you are in development mode so that you the programmer can find out what happened.

2.     If you want an object to have a life beyond the life of the current thread, create it in another one

This can be a bit tricky, but the lives of these objects are bound to threads for a reason, if the thread dies, it is assumed that the data associated with it should die as well.  Try and take a look at the problem you are trying to solve and see where the memory should be allocated.

In conclusion, memory/thread management isn’t magical but has some real underlying rules associated with it.  I hope that this article has been useful to those who read it.  Feel free to comment/correct it.

A

[Been bitten by LabVIEW]

Is this analysis correct?  Or perhaps nobody is interested or understands what I'm saying?

A

[Ben]

Been busy !

I do like the garden analogy. The following are trivia on this subject.

1) A spawned VI can open a ref to itself to keep itself alive.

2) I had a queue on a RT target that created by an Action Engine that was served via VI server to allow remot access. When the TCP/IP connect went down the connetion to the VI server went away and the refs to the VIs served by VI server were closed. Since the queue was created by that VI the queue went away. I tossed the queue and converted to round-robbin buffer.

3) ...\vi.lib\Utility\sysinfo\threadconfig.vi     will let you control the number of threads.

4) In LV 8 and above we have mulitple yards (projects) each of which have their own gardens. It takes more work but it is possible to talk across the fence but there is no way to share the resources ( queues, gardens) acroos yards.

Now back to hanging that wall-paper

Ben

[Been bitten by LabVIEW]

I thought that the garden analogy was very organic. 😄

1. I knew about the self opening refnum, I didn't add it because I thought it was implied.  But a good call.

2. you could have used the main thread to create the queue and passed it to the Engine, that way the queue wouldn't have died and I find that queues are more memory and processing efficient, though when I was using it, I was passing the array around, making it grow and shrink which made for quite a bit of overhead.

3. theadconfig.vi is interesting.  Wonder if it would fix the problems I am having with the environment crashing.  Have set the affinity to 1 CPU to stop a lot of that, but still occurs.  But it isn't very clear as to what it means.  How can you have 'no threads'?  I can still spawn threads no problem.  Process Explorer is interesting.  Looks like more OS threads are being spawned.  I guess that LV does some interesting task switching in the background.  I wonder how this affects how the sync bugs I am having.

4. Sounds like seperate processes.

---

@Ben wrote:

Been busy !

I do like the garden analogy. The following are trivia on this subject.

1) A spawned VI can open a ref to itself to keep itself alive.

2) I had a queue on a RT target that created by an Action Engine that was served via VI server to allow remot access. When the TCP/IP connect went down the connetion to the VI server went away and the refs to the VIs served by VI server were closed. Since the queue was created by that VI the queue went away. I tossed the queue and converted to round-robbin buffer.

3) ...\vi.lib\Utility\sysinfo\threadconfig.vi     will let you control the number of threads.

4) In LV 8 and above we have mulitple yards (projects) each of which have their own gardens. It takes more work but it is possible to talk across the fence but there is no way to share the resources ( queues, gardens) acroos yards.

Now back to hanging that wall-paper

Ben

---

[Been bitten by LabVIEW]

Hmmmm, doesn't seem to curb the number of OS threads either.  What is this doing?

[SuperHero_LV]

Dear fracca,

Your post has helped me. But I want to know more as m facing big problem in thread managment. I am making one automated system for testing heavy duty machines. For that I have to make different vi's and a mother vi.Mother vi will have buttons which will be opening the particular test window. While in all test windows i have put a logic to get back to main screen.

Moreover I have used global variales total 5 no. that to of numeric array to get data in report. But I am facing a frustrating problem . my system is getting hang.

Its veru crucial for me to rectify the problem and complete the system.

Please suggest me some good technic so that my system can become more reliable.

[Ben]

Start a new thread and post your code along with images of same along with the process required to get to the failing condition.

If the code is buggy then don't think twice about posting it becuase nobody in their right mind will try to steal buggy code. Let people review and comment and follow their suggestions. There have been many an app brought back to life through the assistance of the contributors here.

Take care,

Ben