The two methods Thread.Suspend()
and Thread.Resume()
are obsolete since .NET 2.0. Why? What are other alternatives and any examples?

- 10,212
- 11
- 77
- 108

- 37,408
- 63
- 148
- 190
8 Answers
You'll want to use an AutoResetEvent EventWaitHandle.
Say you want to do something like this (NOTE: don't do this!):
private Thread myThread;
private void WorkerThread()
{
myThread = Thread.CurrentThread;
while (true)
{
myThread.Suspend();
//Do work.
}
}
public void StartWorking()
{
myThread.Resume();
}
Like others have said, this is a bad idea. Even though only using Suspend on its own thread is relatively safe, you can never figure out if you're calling Resume when the thread is actually suspended. So Suspend and Resume have been obsoleted.
Instead, you want to use an AutoResetEvent:
private EventWaitHandle wh = new AutoResetEvent();
private void WorkerThread()
{
while(true)
{
wh.WaitOne();
//Do work.
}
}
public void StartWorking()
{
wh.Set();
}
The worker thread will wait on the wait handle until another thread calls StartWorking. It works much the same as Suspend/Resume, as the AutoResetEvent only allows one thread to be "resumed".

- 2,574
- 3
- 24
- 26
-
2This solves typical Suspend/Resume situations and avoids obsolete warnings. – Marc Climent Oct 26 '10 at 15:33
-
This means that you have to put threading logic *inside* your thread. suspend resume allows you writing code that is blissfully unaware of any threadin whatsoever. – Andrew Savinykh Dec 09 '13 at 07:05
-
@zespri: uhh, how? `Suspend()` and `Resume()` are methods on the `Thread` class which has to do with, you know, threading. They're bad methods for the same reason that terminating a process is worse than asking it to stop. – siride Nov 25 '14 at 21:32
-
@siride you always should strive for modularity. If you can write your code in a way that your worker thread does not have to do any thread management and call any methods on the `Thread` class at all - you've done good. Isolating all thread management code outside your worker threads is ideal - unfortunately not very often achievable. `Suspend` / `Resume` in particular is (was) one scenario when this is possible. – Andrew Savinykh Nov 25 '14 at 21:45
-
@zespri: actually, events are more abstract. (1) They don't have to be used with threads at all. (2) They answer the question "is some condition true such that I can proceed?" without reference to were that condition is set. (3) Suspend/Resume can *only* be used with threads, so they actually offer no abstraction over threading at all. – siride Nov 26 '14 at 00:54
-
This method will only work for ONE THREAD, in general when using multi-threading you will have MULTIPLE worker threads. Incidentally the Suspend/Resume method will work fine for multiple threads. Honestly considering that no matter how you suspend a thread you're still suspending any handlers the logic behind why Suspend/Resume is considered deprecated or bad practice when clearly even in the example above it will work just fine, is a whole bunch of MS nonsense. – srcspider Sep 17 '15 at 12:40
The good alternatives all work by the thread reaching a point where it is happy to wait. Suspend was dangerous because it could suspend the thread while it was holding a lock on a mutex - a recipe for deadlocks.
So what your thread needs is a ManualResetEvent that it can Wait on - at a time when it is safe for it to do so, when it is not holding any locks.

- 114,894
- 38
- 205
- 284
-
Good point with the ManualResetEvent. You can also use an AutoResetEvent. – Szymon Rozga Dec 19 '08 at 21:04
This is the best tutorial ever for Thread (for C#): http://www.albahari.com/threading/
For wait you need to use .Join() on the thread. This will wait until tread finish is job. Other wise you will need to use Wait/Pulse.

- 136,852
- 88
- 292
- 341
you can use ManualReset instead of AutoReset:
public class Worker
{
ManualResetEvent _shutdownEvent = new ManualResetEvent(false);
ManualResetEvent _pauseEvent = new ManualResetEvent(true);
Thread _thread;
public Worker() { }
public void Start()
{
_thread = new Thread(DoWork);
_thread.Start();
Console.WriteLine("Thread started running");
}
public void Pause()
{
_pauseEvent.Reset();
Console.WriteLine("Thread paused");
}
public void Resume()
{
_pauseEvent.Set();
Console.WriteLine("Thread resuming ");
}
public void Stop()
{
// Signal the shutdown event
_shutdownEvent.Set();
Console.WriteLine("Thread Stopped ");
// Make sure to resume any paused threads
_pauseEvent.Set();
// Wait for the thread to exit
_thread.Join();
}
public void DoWork()
{
while (true)
{
_pauseEvent.WaitOne(Timeout.Infinite);
if (_shutdownEvent.WaitOne(0))
break;
// Do the work..
Console.WriteLine("Thread is running");
}
}
}

- 503
- 2
- 7
- 17
-
Tried this and it did not work. I put a breakpoint on the _pauseEvent.WaitOne line and after pressing F10 it moved on to the the next line and carried on running the thread. – Paul McCarthy Jun 06 '20 at 17:35
That one is too long. What I need is a quick example codes to use. I found one from the discussion and answered by Mark R. Dawson at http://bytes.com/groups/net-c/458947-thread-suspend. It explains the danger of the obsolete methods and how to use AutoResetEvent to notify the second thread to continue processing.

- 37,408
- 63
- 148
- 190
I agree that is a great tutorial. The main reason Suspend() and Resume() are obsolete is because they are pretty dangerous methods. At any point Thread t could be doing anything. Anything. Imagine your thread is reading a file and has a lock on it. You suspend your thread. File stays locked. Same goes for any other resources. Same goes for a lock on a mutex.

- 17,971
- 7
- 53
- 66
The reasons why Thread.Suspend()
and Thread.Resume()
are obsolete or removed in .NET are largely the same reasons why Thread.suspend()
and Thread.resume()
are obsolete in Java. Compare—
- Java's thread primitive deprecation FAQ (
suspend
"is inherently deadlock prone"), with - Mark R. Dawson's answer on .NET's Thread.Suspend()` ("if you stop a thread in mid execution you can run into deadlock and race conditions").

- 32,158
- 14
- 82
- 96
Solution: Have a thread only resume another thread if the other thread has suspended itself. Thus, the first thread only resumes the other thread if the other thread suspended itself (ie. its ThreadState = Suspended), and, thus, made itself ready to be resumed. This seems safe & flawless.
Or, am I not understanding .Net threading?

- 7,989
- 15
- 69
- 148