Thread.sleep vs Monitor.Wait vs RegisteredWaitHandle?
.net, .net-4.0, c#, clr, multithreading
Solution
Both `Thread.Sleep` and `Monitor.Wait` put the thread in the `WaitSleepJoin` state:
WaitSleepJoin: The thread is blocked. This could be the result of calling Thread::Sleep or Thread::Join, of requesting a lock — for example, by calling Monitor::Enter or Monitor::Wait — or of waiting on a thread synchronization object such as ManualResetEvent.
`RegisteredWaitHandle` is obtained by calling RegisterWaitForSingleObject and passing a `WaitHandle`. Generally all descendants of this class use blocking mechanisms, so calling `Wait` will again put the thread in `WaitSleepJoin` (e.g. `AutoResetEvent`).
Here's another quote from MSDN:
The RegisterWaitForSingleObject method checks the current state of the specified object's WaitHandle. If the object's state is unsignaled, the method registers a wait operation. The wait operation is performed by a thread from the thread pool. The delegate is executed by a worker thread when the object's state becomes signaled or the time-out interval elapses.
So a thread in the pool does wait for the signal.
Problem
(the following items has different goals , but im interesting knowing how they "PAUSEd") questions `Thread.sleep` - Does it impact performance on a system ?does it tie up a thread with its wait ? what about `Monitor.Wait` ? what is the difference in the way they "wait"? do they tie up a thread with their wait ? what about `RegisteredWaitHandle` ? This method accepts a delegate that is executed when a wait handle is signaled. While it’s waiting, it doesn’t tie up a thread. so some thread are paused and can be woken by a delegate , while others just wait ? spin ? can someone please make things clearer ? edit http://www.albahari.com/threading/part2.aspx