I need a solution to perform arbitrary pause. The delay accuracy is irrelevant. What is the practical difference in such scenario between WaitHandle.WaitOne Method (TimeSpan) and Thread.Sleep Method. Are there any better solutions?
-
'Better' depends on the circumstances. Waiting is basically wrong so no 'best practice' here. – H H Jan 22 '14 at 11:50
-
2What is bad in waiting when all I need is only waiting? I just wonder which method is better from performance perspective or if they behave in the same manner under the hood, then I will make my decision basing on other factors such as readability. – Ryszard Dżegan Jan 22 '14 at 11:57
-
Why would you create an `AutoResetEvent`, call `WaitOne`, dispose the event, when you can simply do `Thread.Sleep`? – Henrik Jan 22 '14 at 12:02
-
@Henrik I can invoke _WaitOne_ many times in the loop without disposing _AutoResetEvent_. What would be the difference then? Ok, one minus is that I need to create an instance of wait handle, but I do that only once, so it is negligible. – Ryszard Dżegan Jan 22 '14 at 12:10
3 Answers
If your spec says something like 'Always wait at least two seconds before continuing', use Sleep().
If your spec says something like 'Wait for up to two seconds for a signal from another thread and return an error if timed out' use an event object.
It's basically that simple.
There are essentially no 'performance differences' re. timing accuracy since both calls use the same mechanism for timeouts.
'Better' solutions - what is 'better'? Better in what respect?

- 24,453
- 3
- 36
- 60
1.Thread.Sleep(timeout) causes an unconditional wait before execution is resumed.
2.WaitOne(timeout) causes the thread to wait until either
- the event is triggered,
- The timeout is reached

- 27,666
- 26
- 83
- 129
-
-
It's depends on your requirements.I always prefer signal based synchronization eg.WaitOne – santosh singh Jan 22 '14 at 12:02
-
Where is the part that telling about performance difference between waiting in 1st or 2nd manner? – Ryszard Dżegan Jan 22 '14 at 12:12
-
My problem with Sleep is that when you want to cancel it, you need to raise an exception when killing the thread. With the signal, you can cancel it more beautifully. – Sauleil Jul 19 '16 at 17:26
I would argue against ever using Thread.Sleep(...)
... simply because I dislike blocking a thread unnecessarily... So using a WaitHandle
I think is the superior option.
Alternative
If you're code's elegance will suffer from using WaitHandle
, then have you considered await Task.Delay(...)
? This will give functionality simliar to Thread.Sleep(...)
without blocking the thread.

- 10,063
- 9
- 49
- 74
-
?? Waiting on an event handle blocks the thread, just like sleep() calls. – Martin James Jan 22 '14 at 19:25
-
@MartinJames But without blocking the thread... `Task.Delay()` actually uses a timer. – poy Jan 22 '14 at 19:57
-
1Asynchronous execution on another thread, eg. by Task.Delay(), is surely possible, but the OP is asking about synchronous delays in the calling thread. – Martin James Jan 23 '14 at 08:17