Why is Thread.Sleep so harmful

by

The problems with calling Thread.Sleep are explained quite succinctly here:

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

Thread.Sleep(n) means block the current thread for at least the number
of timeslices (or thread quantums) that can occur within n
milliseconds.
The length of a timeslice is different on different versions/types of
Windows and different processors and generally ranges from 15 to 30
milliseconds. This means the thread is almost guaranteed to block for
more than n milliseconds. The likelihood that your thread will
re-awaken exactly after n milliseconds is about as impossible as
impossible can be. So, Thread.Sleep is pointless for timing.

Threads are a limited resource, they take approximately 200,000 cycles
to create and about 100,000 cycles to destroy. By default they
reserve 1 megabyte of virtual memory for its stack and use 2,000-8,000
cycles for each context switch. This makes any waiting thread a
huge waste.

The preferred solution: WaitHandles

The most-made-mistake is using Thread.Sleep with a while-construct (demo and answer, nice blog-entry)

EDIT:
I would like to enhance my answer:

We have 2 different use-cases:

  1. We are waiting because we know a
    specific timespan when we should continue (use Thread.Sleep, System.Threading.Timer or alikes)

  2. We are waiting because some condition changes some time …
    keyword(s) is/are some time! if the condition-check is in our code-domain, we
    should use WaitHandles – otherwise the external component should
    provide some kind of hooks … if it doesn’t its design is bad!

My answer mainly covers use-case 2

More Related Contents:

  1. Compare using Thread.Sleep and Timer for delayed execution
  2. How accurate is Thread.Sleep(TimeSpan)?
  3. How to keep a .NET console app running?
  4. How to update GUI with backgroundworker?
  5. How to correctly implement a BackgroundWorker with ProgressBar updates?
  6. Is the ++ operator thread safe? [duplicate]
  7. Reliably stop System.Threading.Timer?
  8. Cancelling a Task is throwing an exception
  9. Monitor vs lock
  10. How to check if Thread finished execution
  11. EF Data Context – Async/Await & Multithreading
  12. Process queue with multithreading or tasks
  13. Using string as a lock to do thread synchronization
  14. Raise Events in .NET on the main UI thread
  15. Calling async method on button click
  16. Can you link to a good example of using BackgroundWorker without placing it on a form as a component?
  17. Throw a NullReferenceException while calling the set_item method of a Dictionary object in a multi-threading scenario
  18. Is this thread.abort() normal and safe?
  19. C# Threading/Async: Running a task in the background while UI is interactable
  20. Should thread-safe class have a memory barrier at the end of its constructor?
  21. Cross-Process Locking in C#
  22. Faulted vs Canceled task status after CancellationToken.ThrowIfCancellationRequested
  23. Read and process files in parallel C#
  24. Multiple UI Threads – Winforms
  25. How to exit all running threads?
  26. Access to disposed closure in C#?
  27. Return a value from an Event — is there a Good Practice for this?
  28. Update label from another thread [duplicate]
  29. SqlConnection Thread-Safe?
  30. Is it good idea to use “Control.CheckForIllegalCrossThreadCalls = false” [duplicate]

Leave a Comment