Sleep() issues
-
pblais wrote:
I don't have anyway to handshake with this device/application.
pblais wrote:
when I tried running my app in one of the newer PCs
pblais wrote:
Now my Sleep()'s are too short.
Maybe the parameter for the Sleep() call or Timer event should be configurable rather than hard coded? :rolleyes: Otherwise at some point your application will be Sleep()ing with the fishes.
led mike
led mike wrote:
Maybe the parameter for the Sleep() call or Timer event should be configurable rather than hard coded?
And use a trackbar for fine-tuning!
-
Hi... If there is a better way to do what I am doing, I'll jump on it. I am using Sleep(milliseconds) in my code to place strategic waits for time to pass. As an example, I need to stop the application because I know that something going on in the real world will take at least 100 msecs to finish and I don't have anyway to handshake with this device/application. So I put a Sleep(100). This has worked ok until recently when I tried running my app in one of the newer PCs with the real fast processor etc. Now my Sleep()'s are too short. Is there a way to figure out what the Sleep() will be in msecs from one PC to another? Also... what is the accuracy of, let's say, Sleep(20). How close to waiting 20 msecs will that be? Like I said earlier, if there is a better and more accurate way to do this the using Sleep(), I am open to all suggestions... Regards and thank you in advance Pierre
As has been said, the number you pass to
Sleep()is just a request. Your thread might not wake up for a minute if some high-priority thread grabs the CPU. Something more accurate thanSleep()seems to be in order, check out multimedia timers and waitable timers.--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ Ford, what's this fish doing in my ear?
-
So you are saying that new fast processors alter time? milliseconds are milliseconds (I thought).
pblais wrote:
Also... what is the accuracy of, let's say, Sleep(20). How close to waiting 20 msecs will that be?
I believe the accuracy of Sleep() can vary from +-10ms to +-55ms, depending on the system. A possibly interesting article: Precision is not the same as accuracy[^]
-
pblais wrote:
I don't have anyway to handshake with this device/application.
pblais wrote:
when I tried running my app in one of the newer PCs
pblais wrote:
Now my Sleep()'s are too short.
Maybe the parameter for the Sleep() call or Timer event should be configurable rather than hard coded? :rolleyes: Otherwise at some point your application will be Sleep()ing with the fishes.
led mike
-
led mike wrote:
Maybe the parameter for the Sleep() call or Timer event should be configurable rather than hard coded?
I like that idea... How would I make configurable?
-
Mark Salsbery wrote:
So you are saying that new fast processors alter time? milliseconds are milliseconds (I thought).
Everyone likes a wise cracker
:) You're the one that stated "Now my Sleep()'s are too short" If you choose to use a timer then you'll need to use a multimedia timer. Chances are a WM_TIMER through the SetTimer API is going to be just as inaccurate. I agree with another poster that the problem is probably related to the time the thread's awake, not the time it's suspended in Sleep(). Do you do I/O with the external device you are trying to sync to? If so, is there any way you can use overlapped I/O or soething to make it a bit more event driven instead of trying to fine- tune timeslices of threads? Mark
-
pblais wrote:
How would I make configurable?
Instead of
Sleep(100)something like this:Sleep( Config.Milliseconds);where the number in that variable is provided by a user or administrator.led mike
:((
-
:((
-
:laugh: The whole thing brings back memories of my first computer job - interfacing with a home-brewed laser scanner. All the magic numbers in the legacy code, and how the new 386 CPU messed it all up LOL! To this day, it's still referred to (by myself and my business partner, who worked with me then) as the Laser Bread Slicer (that, we figured, was the extent of its accuracy). So, typical tech support goes something like "See the edit box labeled 'Fudge Factor'? Try entering 203 insead of 198 and see if that fixes it." Thanks man...I thought I had successfully repressed those memories :laugh:
-
:) You're the one that stated "Now my Sleep()'s are too short" If you choose to use a timer then you'll need to use a multimedia timer. Chances are a WM_TIMER through the SetTimer API is going to be just as inaccurate. I agree with another poster that the problem is probably related to the time the thread's awake, not the time it's suspended in Sleep(). Do you do I/O with the external device you are trying to sync to? If so, is there any way you can use overlapped I/O or soething to make it a bit more event driven instead of trying to fine- tune timeslices of threads? Mark
Mark Salsbery wrote:
Do you do I/O with the external device you are trying to sync to? If so, is there any way you can use overlapped I/O or soething to make it a bit more event driven instead of trying to fine- tune timeslices of threads?
Yes sometimes. I am writing test software. Sometimes I have to wait for another piece of test equimpmen to go through it's boot up self test and I have no way knowing when it is done. I do know that it takes it approximately 300 mSec. So I put a Sleep(350) in my code to wait for it. I have recently found, on some newer/faster PCs that the application isn't waiting long enough...