Windows Sleep precision

[DragoRosso]

There's usually better ways to do it rather than interleaving e.g. poll and sleep calls, but just about everybody does that sort of thing now and again even if they don't like to admit it.

Well maybe something better than the 80s techniques (polling and sleeping) can be done ... now (for decades now) there are waitfor methods....
THREADs can be put in standby (even infinitely) until a specific event (or more events) occurs in this way polling, sleep or other are not necessary.
The use of the sleep() procedure should be considered (like others said), and a well-developed application does not normally need sleep. Threads MUST remain "asleep" until their action is needed.
The WAITFOR... in Windows is linked directly to the operating system kernel.

I use sleep only deterministically (with timebeginperiod(x)) for old hardware procedures, I discovered years ago (many years ago) that WAITFOR is the best way to use a THREAD.

Many years ago, when processor power was still limited, simply using WAITFOR compared to the very old but common "sleep" in the while of a thread I managed to lower the average CPU temperature by over 15 degrees, ensuring greater functionality, duration and reliability.

And forget about Application.ProcessMessages, it is useless and can cause several problems that are difficult to debug. If someone feels compelled to use it, then they need to rethink their application.

[440bx]

The purpose of Sleep is to prevent using 100% of a core for an extended (user noticeable) period of time when doing lengthy calculations.

As far as waiting  for a thread, the simplest method is to have the thread that is doing some work send a message to the U.I thread informing it when it's done.  This method works in a great number of common cases and it is much simpler, not to mention safer, than waiting for one or more threads which can be a source of deadlocks.

Also, polling may sound pedestrian but, it can often be very, very cheap to implement and also very CPU friendly.  For instance, having the U.I check the value of some variable whenever it gets a message.  The variable value check might consume 10 clock cycles which is nothing in the message dispatching loop. 

All that said, there are cases when waiting for an  event of one kind or another is the most efficient implementation but, a lot of common cases can be handled nicely and easily by simply using a message to notify the U.I thread some task is done.

[Sander]

Here is a view from an old guy who grew up with DOS, and only writes windows console programs because you pretty much have to these days.

In my experience (XP32), "sleep" is indeed not very accurate and usually returns late by about
10 to 20 milliseconds. On very rare occasions it returns a little early.
This is good enough for a lot of things where you need a delay, and I never thought of improving the accuracy of it.

On the laptop that I write my software on, Windows steals time in chunks of about 16 milliseconds, and it can and do that whenever it feels like it. This suspiciously corresponds to
60 Hz, but okay, it is what it is.

It all depends on what the "sleep" is for.
One can use a delay in case a piece of hardware needs some recovery time, but I don't think that a "delay from now" is a good way to get something to pace at regular constant  intervals.
Over time, the intended interval can really start to drift.

One of my programs reads a few GPIB instruments at regular intervals for long term (days)
monitoring of things.
For this, I have used a "target time" approach.
The target time for the next instrument loop is set based on the target time of the previous
loop.
The instrument loop checks the keyboard (yeah folks, it's a terminal app..) in between dealing with the instruments one by one. When the instrument loop is done,  I call a wait loop which
fills the remaining time with keyboard checks and other updates until "now" is greater or equal
to the target time, after which a new target time is calculated.
Although the  individual time stamps of the instrument loops can still be off by a few milliseconds, the long term stability of the time interval is very good.

It does the job without delving into threads and event handlers, so it's good enough for me.
It gets easy once you realize that a "tdatetime" is a double precision float which counts in days.
You can actually do direct math with time without the need of specialized "time manipulation" functions.

Sander