Jump to content
John Lokanis

Calling .net and thread starvation

Recommended Posts

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!  :D

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.