An accurate form of Sleep()?

[JamesSchumacher]

In reality the algorithm used to determine thread scheduling can change (and does change) between versions of the OS. It's much better not to make assumptions about exactly how the scheduler functions, but rather to code it up more of like "I don't know how long my thread time slice will be or whether I'll get the complete time slice". The idea to use the maximum amout of CPU available in order to achieve better accuracy is flawed because your thread can be preempted at anytime.

At any rate, since you haven't answered the question in the last couple of posts, it's unlikely I'm going to get a direct answer.

Since I do not work for Microsoft on the OS team, I cannot tell you I can for certain. Does that make you happy?

And actually, achieving better accuracy in terms of checking the performance counter, I have actually indeed proven that I have made it more accurate in terms of when code is executed. My bench tests have proven that.

Look how many test I ran... In more than 90% of the cases my code executed 'on time' so to speak.

It seems as if Sleep() / Wait() functions assume the possibility of preemption or taking code execution time into account (the time slice).

And if my code can be preempted at any time, doesn't that prove it's the scheduler's design that gives your app less total cycles?

I rest my case.

On the other end of the stick, the OS recognizes a tighter 'loop' in which the performance counter is being queried... Does this not in fact prove that the design is NOT flawed?

I know my code can be preempted.

I do not think you realize how much time is actually used up in most applications.

A case in which you are compressing files in the background... The problem is actually the disk access time, that's the bottleneck. Disk access requires longer periods of time... AND... During task switches, the disk reader needs to move around if another app is accessing the hard drive.

It's a combination of things, it's not my application alone that's the problem.

Which is why I related to myself also writing functions that are alternatives to C runtime and STL. In case of the C runtime, they run faster. In the case of STL, run faster sometimes and ALWAYS smaller.

This is like the misconception that inline code will always run faster than out of line code. It's not true. In fact, I have found for functions that do more than just returning a value or doing more than a few operations... Putting the code into an 'out of line' function always nets a faster result than the inline one. EVEN in member functions.