20

So Thread.Sleep() is bad (http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx).

Is there any recommended alternative to simulating a pause in execution of a program? Eg a loop? Although I suppose this involves a lot of overhead in initialising variables, checking the bool condition, etc.

Thanks

GurdeepS
  • 65,107
  • 109
  • 251
  • 387
  • 9
    I want to upvote that article, but I can't. StackOverflow has ruined the rest of the Internet for me. – MusiGenesis Sep 21 '09 at 23:07
  • I want that article to explain why 100% cpu use in a continuous worker loop is a preferred alternative to Thread.Sleep(1). – StingyJack Apr 02 '17 at 18:28

9 Answers9

12

If you are only going to simulate a pause (as in for test purposes), I think Thread.Sleep is a perfectly valid approach. On the other hand, if you are actually waiting for something, some sort of thread-safe signalling mechanism would be better (check the types that inherits WaitHandle).

Fredrik Mörk
  • 155,851
  • 29
  • 291
  • 343
6

simulating a pause

"Simulating" sounds like something you would only do in debugging. Thread.Sleep should be fine.

The main problem with Sleep is that usually you should be waiting for something specific to occur rather than waiting for an arbitrary delay.

The other thing to watch out for is calling Thread.Sleep from a UI thread, which will make the UI unresponsive. Better to disable the parts of the UI that you do not want the user to interact with and then use a Timer control to implement the delay.

Jason Kresowaty
  • 16,105
  • 9
  • 57
  • 84
  • This is a perfect suggestion! It worked they way I wanted it to in my program. I just added another timer to wait a specified time before I move onto another part of the program. – TheDevOpsGuru Aug 25 '10 at 19:18
4

From what you said, you're trying to simulate a pause in execution.

Thread.Sleep is perfectly valid for that. Even the article you linked starts with:

Thread.Sleep has it's use: simulating lengthy operations while testing/debugging on an MTA thread.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
3

I don't agree with the assessment that Thread.Sleep() is "bad". It depends on the situation.

In a console mode program, it might be perfectly appropriate to sleep the thread if you're waiting for something. Perhaps even in a loop: Check the condition, sleep for a bit if it's not satisfied, repeat.

In a graphical program however, normally you would not sleep on the main (GUI) thread. This is because these days GUI interfaces are designed with a single interactive thread. If you sleep on that thread, your whole GUI will appear to "lock up" for the time that you're sleeping. A better situation might be to use some kind of timer (all GUI frameworks have such a concept).

One thing you do not want to do is write a loop that continually checks for some condition to be true, without even sleeping. This will cause one CPU to run up to 100% because the CPU wants to get its work done as fast as possible. Not only is this unexpected from a user point of view, but it's unfriendly because such activity can starve the process that you're actually waiting for of enough cycles to get its work done!

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • 2
    That's what synchronization primitives are for. That's the whole point of the blogpost. – ebo Sep 21 '09 at 22:57
  • But "simulating a pause in the exection of a program" is not what synchronization primitives are for. That's the whole point of the **question**. – Greg Hewgill Sep 21 '09 at 22:59
  • 1
    But you are writing it's ok to use it for communication, which it's not. – ebo Sep 21 '09 at 23:02
  • 1
    You can replace while(true) { Thread.Sleep(period); DoWork(); } with a WaitHandle.WaitOne(timeout) instead. – Alan Sep 21 '09 at 23:03
  • I was not suggesting to use sleeping for communication. My answer is generally agnostic toward the reason *why* you might want to pause execution, but rather I was trying to say that sleeping is a perfectly valid API call and you do not want to try to "simulate" a sleep by writing a sleepless loop. – Greg Hewgill Sep 21 '09 at 23:11
2

If you're waiting for some code or event to occur, you can use wait handles.

Josh
  • 1,001
  • 9
  • 18
1

While the article itself is debatable, I agree with its starting sentence, which addresses your concern

Thread.Sleep has it's use: simulating lengthy operations while testing/debugging on an MTA thread. In .NET there's no other reason to use it.

I believe that's what you are asking about (simulating pauses) and is the main use of Thread.Sleep()

Vinko Vrsalovic
  • 330,807
  • 53
  • 334
  • 373
0

I believe Raymond Chen has recommended to set the thread priority lower

http://blogs.msdn.com/oldnewthing/archive/2009/07/27/9849503.aspx

I don't quite understand why you want to pause every so often. Why not just do the work at low priority? When there are more important things to do, your background thread will stop doing whatever it's doing. When there is an available CPU, then your background thread will do its thing as fast as it can (until something with higher priority arrives).

BlackTigerX
  • 6,006
  • 7
  • 38
  • 48
  • His recommendation is in regards to the "third" use of sleep - to slow down the operation and not consume too much CPU time. The question is about simulating pauses, which is the perfect use for Thread.Sleep. The second use, which the article given in a different answer discusses, is polling - and that's bad. – configurator Sep 21 '09 at 23:44
0

I use the System.Timers:

http://msdn.microsoft.com/en-us/library/system.timers.timer.aspx

Keith Adler
  • 20,880
  • 28
  • 119
  • 189
0

I would be willing to bet that in the majority of cases where a programmer thinks of using Thread.Sleep(), some simple code that uses events would work very well.

We Are All Monica
  • 13,000
  • 8
  • 46
  • 72