Thread Sleep

[fdunford]

I wrote the below function to sleep, while processing the window events. It works well enough, but I'd like to improve the accuracy of the sleep. Example - If you call it with 10 msec (0.010), it can take up to 15 msec of real time before it exits. Any suggestions on making it closer to 10 msec?

    Public Sub Spin(ByVal TimeInSec As Double)
        Dim tsStart As TimeSpan = Date.Now.TimeOfDay
        Dim tsNext As TimeSpan = tsStart
        Dim TimeSlept As Double = tsNext.TotalSeconds - tsStart.TotalSeconds

        'wait for Time seconds
        While TimeSlept < TimeInSec AndAlso TimeSlept >= 0 AndAlso AbortTest() = False
            System.Windows.Forms.Application.DoEvents()
            Sleep(2)
            tsNext = Date.Now.TimeOfDay
            TimeSlept = tsNext.TotalSeconds - tsStart.TotalSeconds
        End While

    End Sub

[cicatrix]

This it the most dreadful way to implement a timer that I've even seen.

Here, read about timers:
http://www.vbforums.com/showpost.php...61&postcount=9

[fdunford]

I totally disagree with your comment. I dont want to use a timer either.

Any constructive suggestions?


Edit: This is in a multi-threadded application where I want the calling thread to process system events instead of sleeping. Implementing it in a time would help how?

[cicatrix]

Windows time will never provide a reliable precision less than 30 ms. Threading.Timer is the most precise instrument available.

[Shaggy Hiker]

What is your objection to the timer? The code you have isn't quite busy waiting, but it gets pretty close. Therefore, the timer would be a superior option in most cases. However, it actually isn't clear whether that sub is in the UI thead or one of the other threads.

[dbasnett]

@fdunford,
Does the code you posted run in the UI thread?

[fdunford]

Yes, Spin() is called from the UI thread.

If I used a timer and replaced Spin() with Thread.Sleep() the GUI would not be serviced. A timer is only called when System.Windows.Forms.Application.DoEvents() is called.

[Shaggy Hiker]

Right. You would use the timer to replace what you are doing in Spin. Better than the date, use a stopwatch for timing, as it will give you better precision. Start the stopwatch, start the timer, and every time the timer ticks do what you are currently doing in each loop (except use the stopwatch elapsed time rather than subtracting times). You still won't be able to get a resolution greater than the resolution of the timer, though.

Of course, that does leave the question of what Spin actually accomplishes. You don't actually DO anything in that method other than spin waiting on nothing. It would allow for a busy wait for a fairly low resolution, probably lower than can actually be achieved using any timer, but what is the point? Busy waiting isn't a great solution for any problem because it ramps your CPU to max, killing performance and gobbling power. In your case, you do pause briefly in each iteration, which should slightly mitigate the cost of the busy wait, but is that enough? What are you doing that requires such a costly timing cycle?

[dbasnett]

When you execute Thread.Sleep or Application.DoEvents (a big no-no in its own right) you have no control over when you will get dispatched to again.

[minitech]

You can probably change it to:

Public Sub Spin(ByVal ms As Integer)
        Dim d As Date = Date.Now
 
        'wait for Time seconds
        While Date.Now.Subtract(d).TotalMilliseconds < ms
            If AbortTest() Then Exit While
            Application.DoEvents()
        End While
 
    End Sub