You don’t use the sleep as a timer but just to make the game use the minimum amount of cpu percentage possible. You would just make sure the sleep interval is way smaller than the largest amount of time it would sleep. For my purposes, such as moving a projectile across the screen in a videogame much faster than one pixel a millisecond, sleep(0) works, I think. It should be used to make the program use the least percentage of the cpu as possible and execute as frequently as possible. On a system with a near 0% load on the cpu in task manager, I wrote a simple console program and the sleep(0) function slept for a consistent 1-3 microseconds, which is way less than a millisecond.īut from the above answers in this thread, I know that the amount sleep(0) sleeps can vary much more wildly than this on systems with a large cpu load.īut as I understand it, the sleep function should not be used as a timer. Sleep function that is way less than a millisecond-maybe Because then you could just lock on a mutex that nobody ever releases, and when the timeout is reached, continue on… Timeouts are set with boost::system_time + boost::milliseconds & cie (xtime is deprecated). I wonder if Boost-timed locks have a better precision.
#WINDOWS MILLISECOND CLOCK WINDOWS#
So, maybe the OP wants something that will roughly work most of the time on an idling system, and be able to ask for micro second scheduling! I actually would want that on Windows too.Īlso Sleep(0) sounds like boost::thread::yield(), which terminology is clearer. In that condition, I happend to have measured the Linux usleep command that respected the requested sleep time very closely, down to half a dozen of micro seconds. Tickless kernels exists to help improve laptops batterly life: c.f. Windows Vista has it and Linux has it since 2.6.16. But nobody wants to admit that sometimes, on an idle system, the usleep command can be very precise. Like everybody mentioned, there is indeed no guarantees about the sleep time. A one ms spin does not hurt considerably on multi-core system, when the affinity mask for the calling thread and the service thread are carefully handled.Ĭode, description, and testing can be visited at the Windows Timestamp Project If care is taken, this can run very well, particulary on multi-processor or multi-core systems. However, microsecond resolution may force the service thread to spin on a high resolution time service for at most one interrupt period (~1ms). The service thread can be of big complexity and it may offer system wide services like timed events at microsecond resolution. This way any thread can “sleep” or wait for any time. The “sleeping” thread will setup this thread and then pause at the wait function until the service thread will set the event signaled. In order to have a thread sleeping for any time, also times in the microsecond regime, the thread needs to setup some service thread which will generate an event at the desired delay. A wait function like WaitForSingleObject() can wait for an event. Sleep(0) is an asynchronous service, the call will force the scheduler to react independent of an interrupt.Ī second way is the use of a waitable object. This way the thread will stop until the scheduler forces the thread to get cpu service again. This is a very powerful tool and it is not used as often as it should! It relinquishes the reminder of the thread’s time slice. There is one exception wich allows us to escape from the fact that it may be impossible to sleep for less than the interrupt period: It is the famous Sleep(0).
They just can’t put the correct number into the ActualResolution format. It may be set to something close to 1 ms, some hardware even allows to run at interrupt periods of 0.9765625 ( ActualResolution provided by NtQueryTimerResolution will show 0.9766 but that’s actually wrong. However, this depends on settings of the multimedia timer resources. Generally a sleep will last at least until the next system interrupt occurs.
0 kommentar(er)
