Sleep function
Applies to: desktop apps only
Suspends the execution of the current thread until the time-out interval elapses.
To enter an alertable wait state, use the SleepEx function.
Syntax
VOID WINAPI Sleep( __in DWORD dwMilliseconds );
Parameters
- dwMilliseconds [in]
-
The time interval for which execution is to be suspended, in milliseconds.
A value of zero causes the thread to relinquish the remainder of its time slice to any other thread that is ready to run. If there are no other threads ready to run, the function returns immediately, and the thread continues execution.
Windows XP: A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution. This behavior changed starting with Windows Server 2003.A value of INFINITE indicates that the suspension should not time out.
Return value
This function does not return a value.
Remarks
This function causes a thread to relinquish the remainder of its time slice and become unrunnable for an interval based on the value of dwMilliseconds. 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. If dwMilliseconds is greater than one tick but less than two, the wait can be anywhere between one and two ticks, and so on. To increase the accuracy of the sleep interval, call the timeGetDevCaps function to determine the supported minimum timer resolution and the timeBeginPeriod function to set the timer resolution to its minimum. Use caution when calling timeBeginPeriod, as frequent calls can significantly affect the system clock, system power usage, and the scheduler. If you call timeBeginPeriod, call it one time early in the application and be sure to call the timeEndPeriod function at the very end of the application.
After the sleep interval has passed, the thread is ready to run. If you specify 0 milliseconds, the thread will relinquish the remainder of its time slice but remain ready. Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses. For more information, see Scheduling Priorities.
Be careful when using Sleep in the following scenarios:
- Code that directly or indirectly creates windows (for example, DDE and COM CoInitialize). If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses Sleep with infinite delay, the system will deadlock.
- Threads that are under concurrency control. For example, an I/O completion port or thread pool limits the number of associated threads that can run. If the maximum number of threads is already running, no additional associated thread can run until a running thread finishes. If a thread uses Sleep with an interval of zero to wait for one of the additional associated threads to accomplish some work, the process might deadlock.
For these scenarios, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.
Examples
For an example, see Using Thread Local Storage.
Requirements
|
Minimum supported client | Windows XP |
|---|---|
|
Minimum supported server | Windows Server 2003 |
|
Header |
|
|
Library |
|
|
DLL |
|
See also
- MsgWaitForMultipleObjects
- MsgWaitForMultipleObjectsEx
- Process and Thread Functions
- SleepEx
- Suspending Thread Execution
- Threads
Send comments about this topic to Microsoft
Build date: 3/7/2012
The documentation should explain the timer resolution better. When your program starts, the system's timer resolution has a seemingly random value that depends on which programs are running (and apparently, which programs were run and then exited). Common values for the resolution are 15 ms and 1 ms, but a range of values is possible (use timeGetDevCaps to determine this range). AFAICT, calling timeBeginPeriod() changes the system timer resolution for every call you make to a Win32 function with a timeout (e.g., MsgWaitForMultipleObjects() works exactly the same as Sleep() with respect to the timeout) and every call that every other application in the system makes to a Win32 function with a timeout.
The documentation is also unclear about when to call timeBeginPeriod(). If *calls* to timeBeginPeriod() hurt performance/power usage/etc, then why doesn't Win32 just set the timer resolution to 1 ms when Windows starts up? I'm guessing that there is a tradeoff: a higher timer resolution draws more power but rapidly changing between system-clock frequencies hurts performance. Is there ever a time when an application shouldn't call timeBeginPeriod() at the beginning of the program? It seems like an application that needs a high-precision timer should call timeEndPeriod() after being minimimized or idle for a while and timeBeginPeriod() when the user interacts with the program.
- 5/13/2012
- Aliphany
#include <windows.h>
int main ()
{
std::cout << "Message 1\n" ;
Sleep(2000); // number is in milliseconds 1Sec = 1000 MiliSeconds
std::cout << "Message 2 a two seconds after Message 1" ;
return 0;
}
- 1/17/2012
- Sam557
- 10/25/2011
- muertevita
So while it is best to assume that the Sleep() call might return earlier than you requested (as the docs say can happen), in reality that doesn't appear likely to happen.
- 8/27/2009
- parchmenthill
