AutoResetEvent.WaitOne with timeout vs Thread.Sleep

Question

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?

Poop

'Better' depends on the circumstances. Waiting is basically wrong so no 'best practice' here. – Sheer

What 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. – Obese

Why would you create an AutoResetEvent, call WaitOne, dispose the event, when you can simply do Thread.Sleep? – Warlock

@Warlock 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. – Obese

Answer 1

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?

Carrion

Answer 2

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

Toxophilite

Then what is your proposition? Should I use 1st or 2nd? – Obese

It's depends on your requirements.I always prefer signal based synchronization eg.WaitOne – Toxophilite

Where is the part that telling about performance difference between waiting in 1st or 2nd manner? – Obese

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. – Aeriell

Answer 3

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.

Darfur

?? Waiting on an event handle blocks the thread, just like sleep() calls. – Carrion

@MartinJames But without blocking the thread... Task.Delay() actually uses a timer. – Darfur

Asynchronous execution on another thread, eg. by Task.Delay(), is surely possible, but the OP is asking about synchronous delays in the calling thread. – Carrion