measuring time of a profiled "Sleep" function

A few days ago I posted this question: measuring time of a profiled function

(I hope it's ok i'm opening a new thread, I just can't find the old one in the few first p开发者_如何学运维ages)

I noticed that in my profiled process, I call a "Sleep" method - and this is the problem... When I call SuspendThread/ResumeThread - The Sleeping process pauses, but in reality - time moves on!

I figure that "Sleep" is just some kind of a loop that takes the time and stops whenever the difference between the start time and the end time is large enough.

well, suppose that your profiled process needs to sleep for 1 minute.

You suspended the profiled process after sleeping 2 seconds, and went to eat something.

You came back after 15 minutes and resumed the profiled process.

The profiled process measures the time, finds that MORE than 1 minute passed and it stops sleeping.

that's how I made the process sleep too little (time passes on, when the process is suspended, the Sleep takes it into account - but I can't!)...

And now, finally here is my question:

How can I avoid this problem? How can I measure the times of functions like "Sleep" properly?

thanks :)

sleep methods almost never actually perform the "spin" mechanic you're describing- there's no reason to waste so much CPU time when all it really needs to do is set a timer inside the OS, and then simply stop running until reawakened by the timer. If a process that is already frozen due to a sleep call is frozen again because you suspended it, then it's simply suspended twice; the "alarm clock" calls back and releases its suspension, but the application is still suspended because you suspended it. If you unsuspend it before the sleep wears off, your suspend/unsuspend will have simply had no effect.

As such, it is simply impossible for a thread to know or care about why a sleep took a different time from what was expected. It simply was not running code while it was sleeping. It stopped running code, and then it started running code again some time later, and checking the wall clock will simply tell it how long it was out, not what caused it to be frozen during that time. (Maybe it was low priority, and the OS was very busy, and it simply took that long to schedule it to run again after the sleep ended.)

The closest you can do is to write your own sleep method and use it only for debugging purposes. (It should probably call into the system sleep method when not in debugging mode, so you don't have to change the code outside the function- use conditional compilation via #ifdef DEBUG/#endif.) That sleep should do exactly what you suggest: count ticks until the "wall clock" says it's waited long enough, and if there's an unexpectedly large gap between ticks, push the deadline out further because that time didn't "count".

All that said:

Maybe you've asked the wrong question here. Why are you trying to profile sleep anyway, and make it stable across manually stopping the program? Accurate profiling generally goes out the window anyway once you're freezing the program externally- it throws off almost all the timing-related properties of the program, especially with regard to CPU memory cache behavior.

I got it.
I'll just check if the process is already suspended when I suspend it, and if so - I'll consider the time of my manual suspension as well.
thanks everbody :)