In fact this is the usual way and is correct if you want to lock the thread current (which is often the main and therefore locks the entire application).
But in general it is not what you actually want. It is usually only useful in testing and debugging. Locking is different from blocking although the final effect seems equal in many cases.
And even if it is what is desired, it has problems. This creates a thread which is something heavy. Consumes quite a lot memory and spend a lot of processing for its creation and management (context change).
You might be thinking, "So what about the processing?". It takes capacity that could be being used by other applications on a computer. On mobile device is also consuming battery. You really want this or use without thinking about the consequences?
Since most of the time you just want to delay the execution of a code and the locking of the application is an unnecessary or even undesirable effect, you have to do it otherwise.
Before the . NET 4.5 would have to build a more complex code to control this, perhaps using WaitHandles
. But in this version it is possible to use asynchronicity to help.
await Task.Delay(3000);
With the method Task.Delay()
the desired delay is achieved in a much lighter way and with the await
this is done without halting the application.
It is even possible to create a token to cancel and stop the delay, something that may be desirable in some cases.
Behold working in the ideone. And in the .NET Fiddle. Also put on the Github for future reference.
In that question in the OS has some solutions for those using previous version of . NET. Article showing how the TaskDelay()
works and how to play it.
Additional information is that these delays occur through a timer and its accuracy is low. It depends on the operating system. In current Windows, at least for desktop, it revolves around 15ms. So not only is it pointless to use numbers smaller than this but also you can’t have anything out of multiples of this.
It would also add the fact that, with the use of
Task.Delay
, none thread be busy waiting for the timeout. Therefore, it is not equivalent toawait Task.Run(() => Thread.Sleep(3000))
, contrary to what one might think. WithTask.Delay
, threads are all clear, and the operating system will notify our application via an IOCP (I/O Completion Port) 3 seconds later.– dcastro
I agree with the general idea, in a way it was what I put in the reply. I may be mistaken, or I may not have understood what you meant, but in both cases there is a notification from the OS when the interval should end. The difference is only in blocking. The
Sleep()
does not run anything.– Maniero
The difference between
Sleep
andDelay
, yes, it’s "just" in the lock (simply put). I was just clearing the difference betweenawait Task.Delay(x)
andawait Task.Run(() => Thread.Sleep(x))
, that some people think are equivalent. In the first, all threads are free - in the second, a thread from Threadpool is busy.– dcastro