0

My requirement is to handle a thread from a different thread. I am able to do with thread.Suspend(), thread.Resume() and thread.Abort() but I am getting a warning like these methods has been deprecated. Is there any alternative to these methods, I created a dummy console application which is similar to my application please help to to fix this. Below is my code

using System;
using System.Threading;

namespace ThreadingTest
{
    internal class Program
    {
        private static Thread mainThread;

        private static void Main(string[] args)
        {
            mainThread = Thread.CurrentThread;

            Thread connectServerThread = new Thread(new ThreadStart(ConnectServer));
            connectServerThread.Start();

            int i = 0;
            while (true)
            {
                if (i++ % 5000 == 0)
                {
                    Console.WriteLine(i);
                }
            }
        }

        private static void ConnectServer()
        {
            for (int i = 0; i < 20; i++)
            {
                Thread.Sleep(2000);
                if (i % 2 == 0)
                {
                    mainThread.Suspend();
                }
                else
                {
                    mainThread.Resume();
                }
            }
            mainThread.Abort();
        }
    }
}
madan
  • 773
  • 13
  • 38
  • I always to prefer to have a flag in the Thread class (isRunning) and to have a while(isRunning){...} Then you can set that flag to false from outside. – bbrinck Nov 29 '19 at 07:40
  • 2
    You should only send a request to the thread and let the thread (code) manage itself how to handle that request. What if the thread is just writing data to a file and you suspend or abort it? It will end up in corrupted data. – Sir Rufo Nov 29 '19 at 07:44
  • but in my case i have to execute 500 steps or line of code and if i set a flag then in every step i need to check that flag which is not feasible for me to check. – madan Nov 29 '19 at 07:44
  • @SirRufo its a dummy application not actual its implementation is different – madan Nov 29 '19 at 07:46
  • I was talking about threads/tasks in general – Sir Rufo Nov 29 '19 at 07:47
  • What kind of control do you want to have over the execution of the worker thread? Do you want to be able to suspend and resume the execution, or just to cancel it once? – Theodor Zoulias Nov 29 '19 at 07:50
  • not to cancel at once, it may suspend or resume multiple time – madan Nov 29 '19 at 07:52
  • Sure, `Suspend`, `Resume` and `Abort` are very convenient. But they are _broken_, and not in any way that can be fixed. It's not just that these particular methods are deprecated - the whole idea of aggressively controlling other threads is deprecated. You cannot _ever_ use them reliably (except the very special case of tearing down an AppDomain and aborting _your own_ thread). The only safe choice is cooperative control - this allows you to have explicit points in the execution where you decide abort or suspend is safe. – Luaan Nov 29 '19 at 07:56
  • Do you want to suspend the execution in points predefined by yourself, or you prefer the suspension to be handled by the .NET runtime? – Theodor Zoulias Nov 29 '19 at 07:57
  • @TheodorZoulias it will decided on run time only. – madan Nov 29 '19 at 07:58
  • @Luaan I am agree but my requirement is like that way only – madan Nov 29 '19 at 07:59
  • In that case just ignore the warnings, and use the deprecated methods `Suspend`, `Resume` and `Abort`. For suppressing the warnings look [here](https://stackoverflow.com/questions/1378634/is-there-a-way-to-suppress-warnings-in-c-sharp-similar-to-javas-suppresswarnin). – Theodor Zoulias Nov 29 '19 at 08:02
  • There is no safe way to do that. Make sure you make that clear to the people who make those requirements. If you _do_ use Suspend/Resume/Abort, your whole process can randomly break in unpredictable ways and essentially impossible to debug. It may be that you have very special circumstances where that is preferrable, but you need to make that trade-off clear to the stake holders. Your only option if you want this kind of behaviour is to use the deprecated methods - they aren't ever going to be replaced by something else, because they're inherently bad design, and the C# team doesn't like that. – Luaan Nov 29 '19 at 08:03

1 Answers1

1

I would follow the advice in the documentation

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.

And more specifically, the advice the warning provides:

Please use other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore, to synchronize Threads or protect resources

devb
  • 269
  • 1
  • 8