"Delay(x)" function

[VasudevGharpure]

Does the "Delay(x)" function release the CPU to other processes, or is it a clock hogging busy loop?

Thanks.

[Ray.R]

I was under the impression that Delay(x) released the CPU to do other functions for a given amount of time.

However, I no longer am using it because I found that it was a "clock hogging" busy loop.. or at least my program behaved that way. I am using CVI 7.1.

In my application, I am running two threads and needed to wait "a few seconds" for the second CPU to catch up with the first one. I discovered that when using Delay(x), the second process was not being monitored. Maybe I was using it the wrong way. I have since done away with it and created my own rendez-vous point, without using this function.

Hopefully someone can clarify if it is a "clock hogging" busy loop.

Regards,

Ray

[Al_S]

Delay uses 100% of the CPU. Click here for a knowledgebase article describing it.

[Ray.R]

Thanks Al,

You've confirmed my suspicion..

Interesting reading on your link:

"When you call the LabWindows/CVI Delay(double Number_of_Seconds) function, LabWindows/CVI waits for the specified number of seconds before executing the next line of code. However, this is a "busy wait" loop in which the CPU is utilized 100%.
On the other hand, the Windows SDK includes the Sleep(long dwMilliseconds) function, which suspends the execution of the current thread for a specified number of milliseconds. This yields the CPU to other threads and processes, so the current LabWindows/CVI application thread does not tie up the computer's CPU."

I should try the Sleep() function. I didn't realize that ANSI-C supported it..

Ray

[bilalD]

Sleep() isn't part of ANSI-C. It's provided as a part of the Windows SDK. Make sure to include windows.h as the very first header in your C file when using Sleep().

[Ray.R]

Thanks Bilal!

😄

[menchar]

This is interesting - I had asked for details about Delay() implementation some months ago. NI claimed that it's not simply a busy loop - that there were calls to ProcessSystemEvents within the delay. How in the world anyone would have known this, they didn't explain 🙂 But, while this might allow the application to respond to NI events, it doesn't necessarily mean that the calling thread in fact gets suspended. As a result, I've always coded my own delay routine, which loops on a Win32 API Sleep() call, with ProcessSystemEvents() in the loop. This way, the calling thread really does get suspended by the OS, and the GUI stays responsive due to the ProcessSystemEvents call.

There's a "sleep more often" switch that can be selected in the ADE - not sure just what that would do if not cause Delay() to actually suspend - maybe it's for other delay situations inherent in the run-time engine, rather than Delay() calls.

I like using Sleep() - that was you know pretty much what's going on - the thread is suspended and you don't have to infer NI library run-time behavior.

[Ray.R]

I converted some of the code to use Sleep(), which worked nicely.
I will look at some more conversion for a future release.

Ray

[mikie]

CVI has a specific DelayWithEventProcessing(seconds) function.

In my decades use of Delay(), I've never had the impression that any events were processed.