'What are alternative ways to suspend and resume a thread?

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



Solution 1:[1]

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".

Solution 2:[2]

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.

Solution 3:[3]

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.

Solution 4:[4]

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");

 }
 }
}

Solution 5:[5]

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.

Solution 6:[6]

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.

Solution 7:[7]

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—

Solution 8:[8]

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?

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Darcy Casselman
Solution 2 Daniel Earwicker
Solution 3 Patrick Desjardins
Solution 4 Luke
Solution 5 David.Chu.ca
Solution 6 Szymon Rozga
Solution 7 Peter O.
Solution 8 Doug Null