Are you trying to tell me that your monitoring utility calculates and displays this to full floating point precision?
No, that's not what I've tried to say. What I say is very simple: if the thread was giving up part of its time slice then it would NOT show a _consistent_ usage of 100% of a CPU because the thread would actually spend some time _sleeping_.
As far as the utilities to watch the process, those include Process Explorer, Process Hacker and Task Manager among others. They all agree, Sleep(0) causes a thread that has a loop with such a call to consume 100% of a core. Also, the CPU says it too but, a different way, the fan starts revving faster. Not only you can see the 100%, on some machines you can hear it too.
So Sleep(0) is behaving exactly as expected. It will call the scheduler and if there is no other process to schedule (because there are simply not so many tasks on a multicore system), it will immediately be rescheduled resulting in 100% CPU usage anyway.
Absolutely not. Sleep tells the scheduler "don't schedule me", "don't give me clock cycles", it does
not mean "put me to work", it means: for whatever the remaining amount of time I had left in the time slice, I want to do _nothing_. It tells the scheduler, NOT to schedule the thread and, if the scheduler was doing that, that thread could never use 100% of a core.
Sleep does NOT behave as documented. It does NOT. If it did, the thread would not consume 100% of the CPU.
What you guys are saying is that, if some thread calls Sleep(3000) but, the system has nothing to do, the scheduler would reschedule the thread immediately completely disregarding the request to not be given any clock cycles the specified amount of time and, we know that is not what happens _except_ when the call is Sleep(0).
You want to write lousy code that hogs a cpu, put calls to Sleep(0) in there. Be my guest.