Why doesn't a short Delay in a CVI loop give more processor time to other threads.

[hhjalmers]

We are running TestStand 2.0.1 calling DLLs built in CVI 6.0.0 from several threads simultaneously. At the same time other processes e.g. TFTP transfers needs to run on the PC.
In one of our DLLs we have a loop with a short execution time <0.1ms that needs to be run approximately every 10ms.
If the loop is let run at full speed it takes to much processor time from other threads/processes, however introducing a delay of 10ms ( Delay(0.010) ) doesn't seem to give more processor time to other threads/processes.

Experimenting with the three loops below:
a) while(1);
b) while(1) Delay(0.090);
c) while(1) Delay(0.100);
I found that a) and b) took significant processor time from other proce
sses/threads while c) took much less processor time. (What's the magical difference between 90ms and 100ms?)

Experiments were done with Win2000 on Athlon1200 and P4 2.0GHz machines.

How do I run a simple loop every ~10ms without taking a lot of processor time?

[mfukuchi]

Hello,
You can use a CVI timer, and creat a callback for the timer so that it gets called every 10ms. If the callback takes less than ~10ms to execute, then the system can process other events until the callback function gets called again.

[hhjalmers]

Thanks for the answer.
I did some testing and using a timer callback instead of Delay gives much less CPU overhead for periods in the range 10ms - 100ms (timer callbacks also gives more accurate periods in the range 2ms - 100ms).

However the only way I know to use timer callbacks is by calling RunUserInterface () which is a very bad idea in a generic Dll since it's a "Global" function, it affects the caller(s) of the Dll.
(E.g. if the user of a Dll assumes that his GUI will be "locked out" during the call, unless he specifically calls the Dll in a new thread, he will get a nasty surprise when calling a Dll that uses timer callbacks to control it's loops.)