Precision Delay

Curtis Stubbs

I'm having a problem with my delay method. The overhead of the delay function is causing my program to slow down way to much. I go from a 0ms delay doing 7000 iterations in 1.466 seconds to a 1 ms delay doing 7000 iterations in 32.318 seconds. The math doesn't add up. Is there any way to get a more precise delay without slowing it down too much?

It's a multi-threaded app updating a simple graph in real-time:

        public static void DrawData(int[] data, int size)
        {
            myBuffer.Graphics.Clear(System.Drawing.Color.White);
            int x = 0;
            int y = 0;
            for (int i = 0; i < size; i++)
            {
                x = (i + 2) * width;
                y = 200 - data[i];
                myBuffer.Graphics.DrawLine(bluePen, x, 200, x, y);
            }
            myBuffer.Render();
            System.Threading.Thread.Sleep(delay);
        }

5 Replies

Know the answer? Post it — somebody with the same question will find it here.

Vulpes15y ago
What may be confusing the issue here is that Thread.Sleep(0) doesn't execute in the way you might think. What it does is to relinquish the current thread's time slice to the OS immediately, thereby suspending the current thread and allowing other threads to run.

The delay which it produces is therefore unpredictable as you don't know when the OS will reschedule the ceding thread again.
Curtis Stubbs15y ago
I added a check to monitor the delay.

int time = (int)Environment.TickCount;
System.Threading.Thread.Sleep(delay);
actualDelay = (int)Environment.TickCount - time; ;

It's interesting to note that when delay is 0 actualDelay is also 0, but when delay is 1 actualDelay is 15. Also when delay is 16, actualDelay is 30. I am thinking when I set delay to 0 the compilier is optimizing the delay out of the code. It seems to only be accurate up to 15 milliseconds.
Curtis Stubbs15y ago
Actually this doesn't seem to be the problem. I've tried implementing a delay in the current thread with this:

int time = (int)Environment.TickCount;
while (Environment.TickCount - time < delay) ;

But the results were the same.

Also with the Thread.Sleep method if it sleeps for 0 milliseconds it still releases the process. Since the program is running really fast with sleep(0) I don't think this the problem.
Vulpes15y ago
One more thought on this. If the delay is very small, then you could avoid relinquishing the current thread's time slice by using Thread.SpinWait() - see http://msdn.microsoft.com/en-us/library/system.threading.thread.spinwait.aspx.

You'd need to experiment to find the number of iterations needed to provide a given delay on your processor. However, as a rough rule of thumb, 50 iterations is equivalent to 1 microsecond.
Vulpes15y ago
When you call Thread.Sleep(delay) then you're telling the OS that you don't want the current thread to be schedulable for 'delay' microseconds and, AFAIK, this is as accurate as the system will allow.

However, the problem is that when the thread wakes up it may not be scheduled straightaway if your application has other threads running or there are other applications or background processes running which require CPU time.

One thing you could do to improve the probability that the thread would be rescheduled quickly is to increase the priority of the current thread though this may have some undesirable consequences for any other threads that may be running concurrently.