9 January 2011

Thread.Sleep(1) waits approx. 15 ms in stead of 1

Ever noticed how the time Thread.Sleep(int x) waits is not equal to x? I just noticed it happening with 2 threads with different values for the sleep, yet they were running just as quick.
After some research I discovered that the .Net runtime and Windows map this to a lower resolution in time, due to the way they handle threads. According to some sites it is 15.6 ms.
This means that any x between 1 and 15 will have your thread wait 15.6 ms (give or take, as it might be that your thread has to wait a bit more because of other calculations your CPU is processing). Any value between 16 and 31 will have your thread wait 2 x 15.6 ms (i.e. 31.2 ms) etc. The documentation also states that Thread.Sleep(int x) does not wait exactly x milliseconds, but rather "at least" x milliseconds.
For me, this is not a problem, I have just set the thread that was supposed to go slower to a different value, to make sure it actually runs slower. But just out of curiosity I have done some more research into how to solve it if you really want to have your thread sleep for a more precise period of time.
It seems the MultiMedia API's can help with that. I have tested the following code and it allowed me to set the sleep to a millisecond precisely.

5 January 2011

ThreadAbortException on Response.Redirect(), Response.End() and Response.Transfer()

If you have ever used a call to Response.Redirect("url"), Response.End() or Server.Transfer() within a try block, you will probably have noticed that these calls always throw a ThreadAbortException.
This is normal behaviour, but can mess up your program if the corresponding catch is executed unexpectedly.
To avoid this, catch the ThreadAbortException in a separate catch, or write a try/catch around the call.
For instance, if you have:

try
{
    Do something here;
    
    Response.Redirect("some url");

    Do some more work;
}

catch(Exception ex)
{
    Do something useful with the excepion here;
}

You can rewrite it like so: