Click here to Skip to main content
11,796,393 members (72,208 online)
Rate this: bad
Please Sign up or sign in to vote.
See more: C++ C++/CLI C MFC ATL WTL STL

I need my program to sleep 1 microsecond, but Sleep() can not do this.

So, can I use select() instead of Sleep() to do this?



Does the above approach have any problems?

Posted 13-Aug-09 20:48pm
Edited 16-Oct-09 4:10am
Albert Holguin at 19-Dec-11 13:09pm
Are all those tags really applicable (I doubt it)? Tag appropriately please.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

hanlei0000000009 wrote:
I need my program sleep 1 microsecond, but Sleep() can not do this.

Neither can any other API do this (under Windows). Windows was never designed to provide this kind of functionality (it is not a real-time OS).

If you use something like Sleep(2), your program may sleep for 2 milliseconds, may be 3, or 4, or say even 100 ms. There's no guarantee about this. The thread scheduler tries its levels best to put your thread to an 'unschedulable' state for as close as possible, to what you've asked. But, it can almost never be exact.

So, while Windows cannot even promise you the precision of milliseconds, you can forget microseconds, which is 1000 times the precision of milliseconds!
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

Yeah, that's not happening...

Why 1 microsecond, FFS? What are you trying to do? Because there may well be a better way.
Albert Holguin at 19-Dec-11 13:14pm
That's a good question...
Rate this: bad
Please Sign up or sign in to vote.

Solution 4

Just because the API definition of select() takes its timeout value in microseconds, that doesn't mean that every operating system that supports the Socket API has to provide microsecond resultion on their timers. In fact, almost no operating system does.

As Rajesh said, Windows (Unix, Linux, VMS, yada yada) say that your call (Sleep(), select(), etc) will return is no less than 'x' time (milliseconds, microseconds) but that does not guarantee "no more than 'x'"

So if your application requires this level of time constraint, you're using the wrong operating system. You need a real-time kernel designed to guarantee high speed interrupt timings.
Marcus Kramer at 19-Dec-11 13:23pm
Nice answer, but the question is over 2 years old... :)
Chuck O'Toole at 19-Dec-11 13:25pm
Ha, didn't see that. It popped up on the radar because of solution 3. Prashant answered the original question a few 20 minutes before I did so I just followed through.
Albert Holguin at 19-Dec-11 14:53pm
I didn't notice that either... it was in the "active questions" list... oh well...
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

System.Threading.Thread.Sleep(your time).
johny10151981 at 19-Dec-11 20:43pm
you provide a .Net solution, and as you can see from above discussion its clear that in a multi-tasking, non real-time operating system sleep wont do a big deal

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Maciej Los 570
1 Abhinav S 392
2 OriginalGriff 340
3 CPallini 269
4 KrunalRohit 249
0 OriginalGriff 2,012
1 Maciej Los 1,615
2 KrunalRohit 1,310
3 CPallini 1,015
4 Richard MacCutchan 828

Advertise | Privacy | Mobile
Web04 | 2.8.151002.1 | Last Updated 19 Dec 2011
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100