The operation
System.Threading.Thread.Suspend
and
Resume
are now considered obsolete, for a good reason, as these operations are dangerous. See
http://msdn.microsoft.com/en-us/library/system.threading.thread.aspx[
^].
Read this from
http://msdn.microsoft.com/en-us/library/system.threading.thread.suspend.aspx[
^]:
"Caution
Do not use the Suspend and Resume methods to synchronize the activities of threads. You have no way of knowing what code a thread is executing when you suspend it. If you suspend a thread while it holds locks during a security permission evaluation, other threads in the AppDomain might be blocked. If you suspend a thread while it is executing a class constructor, other threads in the AppDomain that attempt to use that class are blocked. Deadlocks can occur very easily."Instead, a thread should be suspended or resumed using the synchronization primitive
System.Threading.EventWaitHandle
. The instance of this class should be used in certain point in code by a working thread in a call to
EventWaitHandle.WaitOne
. If this instance is not set, the thread is put in a wait state by the OS: it is switched off and never scheduled back to execution until awaken (so, in this state is uses zero processor time). It can be awaken if some other thread calls
EventWaitHandle.Set
on the same instance. Other condition for wake-up include timeout of
System.Threading.EventWaitHandle.WaitOne
call (if applied), or a call the
Thread.Abort
or
Thread.Interrupt
called in some other thread. These are the ways to resume the thread from the blocking call to
System.Threading.EventWaitHandle.WaitOne
.
One important application of this method is the Blocking Queue, I provide the full source code in my Tips/Tricks article:
Simple Blocking Queue for Thread Communication and Inter-thread Invocation[
^].
See also my other answers on related topics and links to other past answers:
How to get a keydown event to operate on a different thread in vb.net[
^],
Control events not firing after enable disable + multithreading[
^].
—SA