Calling .net and thread starvation

[John Lokanis]

I am seeing strange behaviors in some of my code that looks like thread starvation.  I have some code that checks the timer, enters a loop and then at each iteration of the loop (should be 1 second or less) checks the timer to see if it exceeded the allowed time.  Occasionally, it will timeout with a duration that exceeds the limit by several minutes.  This appears to be as if the VI was frozen and could not iterate the loop for a long time.

The same application has a lot of .NET calls to a database going on in parallel operations.  I am suspecting that those calls are taking a long time and stealing all the threads.

I don't have any ini settings that change the thread count to something other than the default and all my VIs use the 'Same as Caller' execution system.

 

So, my question is, how many simultaneous .net calls can I execute before all my VIs stop getting any CPU cycles? From the research I have done, it looks like 8, but I am not sure if that is correct for LV2011.

Would it help to set the threads per execution system to a larger number in the ini file?

Would it help to make my VIs that call .net execute in a different execution system?

 

This application was built in LV2011 so I need to stick to that environment for now.

 

thanks for any ideas.

 

-John

[Rolf Kalbermatter]

I am seeing strange behaviors in some of my code that looks like thread starvation.  I have some code that checks the timer, enters a loop and then at each iteration of the loop (should be 1 second or less) checks the timer to see if it exceeded the allowed time.  Occasionally, it will timeout with a duration that exceeds the limit by several minutes.  This appears to be as if the VI was frozen and could not iterate the loop for a long time.

The same application has a lot of .NET calls to a database going on in parallel operations.  I am suspecting that those calls are taking a long time and stealing all the threads.

I don't have any ini settings that change the thread count to something other than the default and all my VIs use the 'Same as Caller' execution system.

 

So, my question is, how many simultaneous .net calls can I execute before all my VIs stop getting any CPU cycles? From the research I have done, it looks like 8, but I am not sure if that is correct for LV2011.

Would it help to set the threads per execution system to a larger number in the ini file?

Would it help to make my VIs that call .net execute in a different execution system?

 

This application was built in LV2011 so I need to stick to that environment for now.

 

thanks for any ideas.

 

-John

 

The first approach would certainly be to put your .Net code in a different execution system. That should give your timer code (it is all LabVIEW isn't it?) enough room to do its work.

 

As LabVIEW executes a .Net call the calling thread is basically locked. If you happen to have 8 parallel .Net calls your execution system is blocked. Increasing the number of threads per execution systems is only a bandaid at best. Sooner or later you will manage to use them too and run into problems again. However do you really have that many parallel code execution paths going on that call into .Net?

 

You only have .Net and no ActiveX and Call Library Node calls?

[John Lokanis]

Yes, I typically have 40-100 parallel sub-systems, each with several threads (and at least one dedicated to .net calls to a DB) running at the same time.  Normally a call to the DB via .net executes in milliseconds so there is no issue.  But lately, the DB has been having issues of slow response and deadlocking, which I suspect is causing the .net calls to hang for a long time and starving my LV code of clock cycles.

And yes, all the timer code is LV.  Actually, it is a pure LV system outside of the .net calls for DB access and some occasional XML reading.

 

So, bumping the thread count seems like a good bandaid for the short term without having to recompile the exe.  Changing the execution system from same as caller to something else for the .net code might also help?  At some point I thought I remember hearing that LV will use the other execution systems automatically if one is overloaded, but perhaps I am remembering that incorrectly.

 

Anyone know the ini strings to adjust the execution system threads?

 

Oh, and does it matter how many cores the machine has or will the OS manage the threads across the cores on it's own?

 

thanks,

 

-John

[Rolf Kalbermatter]

At some point I thought I remember hearing that LV will use the other execution systems automatically if one is overloaded, but perhaps I am remembering that incorrectly.

 

That sounds like a bad memory! 

 

Anyone know the ini strings to adjust the execution system threads?

 

There is a threadconfig.vi in vi.lib\Utility\sysinfo.llb that will configure LabVIEW and write the necessary settings into the LabVIEW.ini file. You can then copy them into your application ini file.

 

Oh, and does it matter how many cores the machine has or will the OS manage the threads across the cores on it's own?

 

That should be managed by Windows.

[John Lokanis]

Thanks.  I will give this a try!

[ak_nz]

There is a threadconfig.vi in vi.lib\Utility\sysinfo.llb that will configure LabVIEW and write the necessary settings into the LabVIEW.ini file. You can then copy them into your application ini file.

 

 

I typically have a post-build action that can update the ini file with the appropriate keys. Having written an application with over 20 asynchronous processes running long-time .NET calls it comes in handy. On occasion I have had to create a "wrapper" VI that launches the common SubVI(s) in a  specific execution system so that I can share the load appropriately. The SubVI(s) are obviously configured same as caller.

[John Lokanis]

Does anyone know if it is ok to set the execution system property on a dynamically called VI right before you call the run method?

 

Also, will dynamically called VIs inherit the execution system of their caller if it is not changed in the property node after opening the reference to the dynamic VI?