Well, at the beginning this works fine but after around 90 seconds, suddenly the delay in ::Sleep(1) -> 1 millisecond becomes in a delay of 10 milliseconds.
When I finish the program and run it again, the damage stayed permanently, even when I quit the Visual Studio.
Only it fixes when restarting. So, I have to reboot my PC to re-run it normal, but the problem repeats again after 90 seconds of running the program.
I tested with other parameters delays, (like 2,3,5,10,12,50...) and this only happens when the delay parameter is less than 10ms. It always turns into 10ms.
I was reading the MSDN Sleep function, but I have not found anything.
The system clock "ticks" at a constant rate. If dwMilliseconds is less than the resolution of the system clock, the thread may sleep for less than the specified length of time.
This is inaccurate and should read: "the thread may sleep for more than the specified length of time." And since 1ms is almost certainly smaller than the default resolution of the system clock (12ms on my system), the call should range anywhere from 1 to ~12ms. In other words, the sleep should end on the next "tick" after the call.
That particular paragraph also tells you how to adjust the timer resolution to its minimum.
Sorry, I read that paragraph, but due to my little knowledge I did not imagine that this problem had been related to the overall resolution of the system clock. But now I'm learning a little more.
I have read the link. So to modify the resolution must use carefully timeEndPeriod (1) and timeEndPeriod (1) correspondingly.
But it says it can also reduce overall system performance.
In other forums I read: better don't use Sleep function, but doesn't mention any alternative solution.
I don't know what to decide, whether to continue insist to use the Sleep function or look for another alternative.
The destination of my application is to run permanently 24 hours a day, 365 days a year. So the "task_timer Thread" in 1ms delay (the example above) will never end.