Don't suspend the TCP thread when RT gets busy

[gsussman]

On all of the RT platforms, if the CPU maxes out at 100% the RTOS goes through a sort of "load shedding" and begins suspending non critical threads to lower the CPU overhead and hopefully maintain determinism. One of the first threads that gets suspended is the TCP thread which essentially cuts off the RT target from the ethernet and outside world.

While I understand the concept of the load shedding, I believe that if you have the CPU pushed that hard, then your determinism is out the window anyway. Dropping the TCP thread only serves to disconnect the RT system from the development environment or the built application with no real benefit. I have yet to see a single application that was actually able to accomplish anything substantial after the point that the TCP thread was suspended. In most cases, the high CPU usage happens during the development of the application or when something is critically wrong with the setup of the deployed app. In those cases, it wouldn't matter how many threads you suspended, the CPU will still be maxed out.

It is akin to blowing out a match in the midst of a forrest fire.

I would propose that the RTOS be reconfigured to show the TCP thread as one of the critical threads and keep it from being suspended during high CPU excursions OR give the developer the option to turn this feature on or off throgh the device properties.

[ScotSalmon]

I understand the motivation for this suggestion, as this is indeed a very common failure mode during development, and very frustrating.  However, the cause is not "load shedding" as you put it.  The cause is simply that the application has a time critical thread (or threads) which use, in total, enough CPU that the network threads are effectively unresponsive.  That could be 100%, 99%, maybe even 95% or less, depending on what else is going on.  The system may be functioning correctly; the network may become responsive again in the future.

The bottom line is that LabVIEW RT can't make a thread priority decision for you.  If you feel that your application threads are not, in fact, higher priority than the network threads, then by all means, configure your VI execution properties accordingly, at least during early development.

It's important to note that "priority" on a real-time system is just an instruction to the OS scheduler to tell it which thread to run if multiple threads are ready.  It does not equal "importance".  While getting the network to respond is probably the most important thing to you when your app accidentally hangs the system during development, if you configured your app so that some other thread had higher priority than the network, an RTOS will (and must, by definition of an RT scheduler) obey that.

[Michael_78]

Having the ability to temporarily bump the project debug thread to highest priority during development would be an invaluable feature. Sometimes debugging an accidental timed loop iteration set to zero can be very difficult. Once the target has lost communications there is no way to debug your mistake. As the debug thread is normal priority we would have to remove all timed loops just to re-enable debugging. Please add this option to set the trinity of the debug loop