Why is time-critical thread not interrupting sleepless high priority thread?

Question

Hello,
I have two threads running in the same execution system on a real-time PXI platform. The time-critical thread sleeps using "AI Single Scan.VI", and acquires my data at a rate of 8000 Hz.
I have a slower high priority process that calls a DLL function to calculate some filter coefficients. This function call takes longer than 1/8000 s to complete, and runs in a loop, executing as often as it can (with new data from FIFOs).
I expected the time-critical thread to interrupt the the high priority thread without problem.
I am finding that unless I insert a LabVIEW delay (for example a wait for x ms VI) in the loop, the real-time system stops responding. With a small delay (ie 1 ms), t
he acquisition completes, and a FIFO shuts down the loop of the slow process.
Why do I need a labVIEW delay in the high-priority loop, when the DLL function call itself is quite slow? Even without a DLL call, I would expect the time-critical VI to interrupt, finish its data acquisition, and shut-down the high-priority thread using its FIFO.
Any suggestions?
Thanks in advance,
Frenk

Answer 1

Here are a couple things to try/check:
1) Check the call library node in your high priority VI. If it's orange (runs in UI thread), your high priority VI is actually switching to the UI thread every time your dll runs. That alone is not a problem. But if your TC VI tries to update any control terminals, the TC thread will switch over to the UI thread to access UI resources, possibly while the dll within your high priority VI has a lock on those resources. Why does the dll have a lock on UI resources? Because it was running in the UI thread and got interrupted by the TC thread before it finished doing its business. Not likely, but possible.
2) There's another possible reason you're seeing this behavior. If the TC VI and the high VI call a mutual subVI, the subVI will be elevated to ALWAYS run in the highest priority thread irrespective of the actual caller (in your case, it's the the TC thread). Even when the *high priority VI* calls the mutual subVI, that subVI runs in the time-critical thread, which means there's a thread switch from high to TC, then back to high after the subVI finishes. And because high and TC VIs are in the same exec system, that mutual subVI will always run in the 1 and only TC thread alotted to that exec system.
So, while your TC VI is running, you're in the TC thread. While, your high VI is running, you're in a high non-TC thread, and when your high VI calls the mutual subVI, you're again in the TC thread until the subVI finishes.
So how could this arrangement cause your TC VI to become starved by the high VI? If your TC VI wakes up while the high VI is in the middle of running the mutual subVI, the TC thread responsible for running the TC VI is actually busy (in the middle of running the subVI in your high VI!!!), so the TC thread cannot run your TC VI until it finishes running that mutual subVI.
The fix: make your TC VI run in a different exec system. It will be given its own TC thread that no one else can mess with. When TC VI wakes up, it's guaranteed a TC thread.
I think there's a good reason behind why a mutual subVI ALWAYs runs at the highest priority of all its callers, irrespective of the actual caller's priority...but I can't think of the reason at the moment.