How accurate is Thread.Sleep(TimeSpan)?

I've come across a unit test that is failing intermittently because the time elapsed isn't what I expect it to be.

An example of what this test looks like is:

Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();

TimeSpan oneSecond = new TimeSpan(0, 0, 1);

for(int i=0; i<3; i++)
{
    Thread.Sleep(oneSecond);
}

stopwatch.Stop();

Assert.GreaterOrEqual(stopwatch.ElapsedMilliseconds, 2999);

Most of the time this passes but it has failed on at least on one occasion failed because:

Expected: greater than or equal to 2999 But was: 2998

I don't understand how it could possibly be less than 3 seconds. Is there an accuracy issue with Thread.Sleep or maybe Stopwatch that I'm not aware of?

Just as an update to some of the questions below. The scenario that is being unit tested is a class that allow's one to call a method to perform some action and if it fails wait a second and recall that method. The test shown above is just an approximation of what is happening.

Say I wanted to call a method DoSomething()...but in the event of an exception being thrown by DoSomething() I want to be able to retry calling it up to a maximum of 3 times but wait 1 second between each attempt. The aim of the unit test, in this case, is to verify that when we requested 3 retries with 1 second waits between each retry that the total time taken is greater than 3 seconds.

Solution 1:

Your thread is sharing CPU Time with other threads. The Sleep will end as soon as it is your turn again and the kernel notices the sleep time has elapsed, so it is not that accurate.

CPU load, process priorities, number of concurrent threads, even from other processes, will have effect upon it.

Solution 2:

Thread.Sleep is not intended to be used for precision waking. Really, windows architecture itself is not intended for this kind of thing.

Solution 3:

Quickly experimenting, I notice that a code fragment like...

do { Debug.WriteLine( DateTime.Now.TimeOfDay.TotalMilliseconds.ToString() ); } while ( 1 );

displays the same number multiple times, then jumps to a new number displayed multiple times, etc. The gap between these sets of numbers is consistently 15.625ms which I notice is 1000 / 64.

Looks like Windows timers have a granularity of 1/64th of a second. If you need better than that then I feel your pain, but that's the framework you have to fit within. (Windows isn't a hard real-time OS and doesn't claim to be).

Solution 4:

Thread sleeping and timing/throttling are very different things, and should be treated appropriately. Sleeping a thread is a general task, allowing the system to give other threads and processes the chance to execute without being specific about it. On the other hand, throttling an application or scheduling tasks that need accurate timing should be performed with an explicit timer.

Keep in mind, if you need time-accurate processes or synchronization, you will have a hard time achieving that with a normal process in windows. You would need to utilize windows realtime priorities to successfully achieve accurate timing or throttling, as windows can sleep any thread at any time if it is preempted by another thread.