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.