How to implicitly stop a thread in an object in C #

Question

I have an object containing a workflow. I would like to kill a thread when an object goes beyond.

using System.IO; using System; using System.Threading; namespace tt { class Program { static void Main() { AnotherClass a = new AnotherClass(); a.Say(); } } class AnotherClass:IDisposable { private bool m_Disposed; private readonly AutoResetEvent m_ResetEvent = new AutoResetEvent(false); public AnotherClass() { Thread t = new Thread(wait); t.Start(); } public void Dispose() { Dispose(true); } private void Dispose(bool disposing) { if (m_Disposed) { return; } if (disposing) { Console.WriteLine("inner disposing"); } m_ResetEvent.Set(); Console.WriteLine("Outer disposing"); m_Disposed = true; } private void wait() { m_ResetEvent.WaitOne(); } ~AnotherClass() { Dispose(false); } public void Say() { Console.WriteLine("HellO"); } } } 

The program will just hang there, because the AnotherClass destructor is not called. I know that I can call a.Dispose () to kill the thread. But is there a way to implicitly kill a thread when an object goes out of scope?

Answer 1

No, It is Immpossible. There is no reference counting that can notice that the object no longer has links, so there is no way to do anything when this happens.

The IDisposable interface is used for classes that must do something when the instance is no longer being used, and the call to the Dispose method is how you signal that you are finished with the instance.

The usual way to make sure the object is deleted when you leave the scope is to wrap the code in a using block:

 static void Main() { using (AnotherClass a = new AnotherClass()) { a.Say(); } } 

The using block is the syntactic sugar for the try...finally block:

 static void Main() { AnotherClass a = new AnotherClass(); try { a.Say(); } finally { if (a != null) { ((Idisposable)a).Dispose(); } } } 

Answer 2

Adding Guffa to the answer, I think it’s also important to note that even if you had a way to determine the exact moment when your instance of AnotherClass went out of scope, in that case it simply never will. And so you noticed that your destructor never got it.

The reason for this is that when creating and starting a workflow, the stream is transmitted by a delegate link pointing to the wait() instance method, which comes with an implicit reference to this ( AnotherClass instance), therefore, until your stream itself goes out of scope, it will reference the instance of AnotherClass and prevent it from garbage collection.

Answer 3

You can use exception handling and use the error displayed as an exception in the catch block

Answer 4

If your thread exists to serve the object in the interests of other threads, you should have an open wrapper object for which all threads "interested" in the service will contain strong links, and the service itself will keep a long weak link. This wrapper object should not contain any information that the service should read or manipulate, but should forward all requests for information to an object that both the wrapper and the service contain strong links.

When the server thread is awake, it should periodically check to see if a weak reference to the wrapper object remains. If this is not the case, the server thread should be disconnected in an orderly manner. Note that the server never uses a strong reference to the wrapper — even temporarily — so the wrapper must evaporate as soon as no one is interested.

If the server thread can be blocked indefinitely, waiting for different things to happen, the shell should contain a single link anywhere in the universe for an object that can be finalized, which contains a strong link to the server object; when the finalizer finishes, it must check to see if the long weak link held by the server object retains it. If this is not the case, try to push the server thread (for example, using Monitor.TryEnter/Monitor.Pulse . If the wrapper object is still alive (finalizers can sometimes erroneously run in some resurrection scenarios), or the finalizer could not push the server thread, the final object must re-register to complete.

Using a finalizer object will complicate things; if the server thread can wake itself up periodically, without the need to push, which will simplify the design. However, the finalizer used as described should be relatively robust even in scenarios involving involuntary resurrection.