Develop Reference

Will thread be disposed if an object sets to null

I have a class ClassA
public class ClassA
{
public ClassA()
{
Thread t = new Thread(EndlessLoop);
t.IsBackground = True;
t.Start();
}
private void EndlessLoop()
{
while (True)
{
// do something
}
}
}
and I'm not sure if the thread will be disposed if I set ClassA object to null
ClassA a = new ClassA();
# will the thread exit ?
a = null;
Or maybe I should implement IDisposable, and call it manually?

Once started, the thread will terminate after the routine comes to an end (or Thread.Abort is invoked or the program exits). The Thread class doesn't implement IDisposable so there's no Dispose method to call. To terminate a long-running thread, you could set a flag that the thread checks periodically.
The Thread object is eligible to be garbage collected once it goes out of scope and is no longer referenced. However, the spawned thread will continue running.

Nothing going to happen to the OS thread if you remove last refence to the Thread object corresponding to it - C# Thread object lifetime. The thread will continue to run the code until the method finishes (unlikely in while(true) case shown), thread is terminated with Abort (don't do that - What's wrong with using Thread.Abort()) or process ends.
The only good option is to somehow notify thread's code that it should finish (i.e. using events or even global variable protected by lock). Also consider if using Task and async with corresponding cancellation mechanism would simplify code (it would not solve infinite loop issue but give good framework to write cancellable operations).
Note that you can't "dispose" thread because it does not implement Dispose (Do we need to dispose or terminate a thread in C# after usage?),

how to close a thread containing a blocking method in C#

I create a thread to handle a blocking method in my code. this way, my code can do other things beside running that blocking method.
question: how can I terminate the thread properly? do I have to unblock the blocking method, then terminate the thread. or can I just terminate the thread without worrying about any ugly crashing?

Call yourthread.Abort(). It's not like in the old days where this would cause you to break everything when resources and locks weren't released, now this causes quite a nice exception to be raised that can be handled in the normal way...
http://msdn.microsoft.com/en-us/library/system.threading.thread.abort.aspx
When I say "the normal way" it seems that thread abort exception auto re-raises (quite a nice trick)
http://msdn.microsoft.com/en-us/library/system.threading.threadabortexception.aspx
but that wouldn't stop you being a douche and kicking off another big thing in the catch block...

You have some options. If you don't care if the operation completes when the application is going down you might be better off using a ThreadPool thread via QueueUserWorkItem or (as Servy suggests in comments) set the IsBackground property of your thread to true, which will allow the process to exit without the thread exiting.
If you do care about the operation completing and/or have cleanup logic that needs to be run on shutdown you probably don't really want to use Thread.Abort, at least not as your goto strategy. What I use is something similar to this:
public abstract class DisposableThread : IDisposable
{
private ManualResetEvent exiting = new ManualResetEvent(false);
private Thread theThread;
private TimeSpan abortTimeout;
public DisposableThread():
this(TimeSpan.FromMilliseconds(100))
{
}
public DisposableThread(TimeSpan abortTimeout)
{
this.abortTimeout = abortTimeout;
theThread = new Thread((_) => ThreadProc());
}
protected virtual void ThreadProc()
{
while(!exiting.WaitOne(0))
{
WorkUnit(exiting);
}
ThreadCleanup();
}
public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
exiting.Set();
if (!theThread.Join(abortTimeout))
{
// logme -- the thread didn't shutdown gracefully
theThread.Abort();
while (!theThread.Join(1000))
{
// logme -- the thread is doing something dumb in an exception handler
}
}
exiting.Dispose();
}
// WorkUnit should return as quickly as safe if the exiting handle is set
// If it doesn't the thread will be aborted if it takes longer than abortTimeout
protected abstract void WorkUnit(WaitHandle exiting);
// override if you need to cleanup on exit
protected virtual void ThreadCleanup() { }
}
Which gives your thread a chance to exit gracefully and only aborts if a graceful exit fails.

OK,
found my answer. I gotta declare the threads so that references can be made to them. then, I end the nested thread (which has HandleClientComm()) first, then close the TCP_Client (if not null) and the TCP_Listener. then I end the ListenThread(). also, the TCP_Listener.Pending() method mentioned here Proper way to stop TcpListener must be implemented.

Should I implement IDisposable for a class containing a Thread

I have a class that uses the Thread class:
class A
{
public Thread thread
{ get; set; }
}
Should I implement IDisposable and set Thread property to null?
class A : IDisposable
{
public Thread Thread
{ get; set; }
protected bool Disposed
{ get; set; }
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (!this.Disposed)
{
if (disposing)
{
if (Thread != null)
Thread = null;
}
Disposed = true;
}
}
}
Or not?
Why?

You implement IDisposable only when your class is handling an unmanaged object, resources or other IDisposable objects. A Thread is not an unmanaged object and will get garbage collected when nothing is referencing it or when the process handling it is terminated. Since Thread is not implementing IDisposable, your class referencing it does not need to implement it either.
Optionally, for IDisposable within the scope of a method, they can be wrapped in a using statement and the Dispose() method is automatically called when the scope is exited.

It depends what your thread is doing. If your thread is performing a long running task that may run indefinitely, then I would consider that thread as a resource (which will not be garbage collected). For example consider if the thread is designed to poll some state indefinitely, or consume items from a queue (like a thread-pool thread consumes tasks or a TCP server consumes new connections) etc. In this case, I would say the natural effect of disposing your class would be to free up this thread resource. Setting it to null is not really useful in this case. Rather Dispose should probably involve flagging a synchronization event (or maybe a CancellationToken) to notify the thread that it should finish up its infinite task, and then the disposing thread should wait some time for the thread to finish (join). As always with joins, be careful of a deadlock scenario and consider some alternative action if the thread refuses to terminate. For obvious reasons I would not do this join in the finalizer.
As an example of what I'm meaning, consider the scenario where your class A is actually class MyTcpListener, designed to listen and wait for new TCP connections on a given port indefinitely. Then consider what you expect following (somewhat unlikely) code to do:
using (MyTcpListener listener = new MyTcpListener(port:1234))
{
// Do something here
}
// Create another one. This would fail if the previous Dispose
// did not unbind from the port.
using (MyTcpListener listener = new MyTcpListener(port:1234))
{
// Do something else here
}
Assuming I know the constructor of MyTcpListener creates a listener thread, I would expect that after the Dispose call has returned that the MyTcpListener would no longer be bound to the TCP port - i.e. that the TCP listener thread would have fully terminated. It goes without saying that if you didn't provide some mechanism to stop the listener that there would be a resource leak. The stopping mechanism could be a call to some method "Stop", but I personally think the "Dispose" pattern fits this scenario more cleanly since forgetting to stop something does not generally imply a resource leak.
Your code may call for different assumptions, so I would suggest judging it on the scenario. If your thread is short-running, e.g. it has some known finite task to complete and then it will terminate on its own, then I would say that disposing is less critical or perhaps useless.

Can a timer be abandoned safely

Are Timers in .NET safe to abandon without calling Dispose() or Close()?
static System.Timers.Timer timer = new Timer();
void Main()
{
timer.Elapsed += LogTimer_Elapsed(object, System.Timers.ElapsedEventArgs);
timer.Start();
Thread.Sleep(10000); // Simulate doing something on main thread
}
static void LogTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
DoStuff();
}
Anyone see any problems with this solution?
static QueueLogger()
{
LogQueue = new Queue<KeyValuePair<Logger, LogEntry>>(50);
LogTimer = new Timer();
LogTimer.Elapsed +=new System.Timers.ElapsedEventHandler(LogTimer_Elapsed);
AppDomain.CurrentDomain.ProcessExit += new EventHandler(CurrentDomain_ProcessExit);
}
static void CurrentDomain_ProcessExit(object sender, EventArgs e)
{
LogTimer.Stop();
LogTimer.Dispose();
LogTimer_Elapsed(sender, null); // This is to process any remaining messages in the queue
}
static void LogTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
lock (_locker)
{
while (LogQueue.Count > 0)
{
var queuedLogger = LogQueue.Dequeue();
try
{
if (e != null) queuedLogger.Value.Message += " From " + sender.ToString();
queuedLogger.Key.Log(queuedLogger.Value);
}
catch (Exception ex)
{
OnLoggingError(queuedLogger.Key, "Async Logging error", ex);
}
}
}
}

Galford,
Yes, you can create new event which will fire if your application is about to exit e.g. OnExit and listen to the event when you application's main thread is about to close. Once that is done you can create event logic and do your timer, business or clean up logic in OnExit event. Hope this helps.
Regards

If you do not dispose of it explicitly it will be cleaned up on the garbage collector's finalizer queue. Although this is "safe" you will incur a performance penalty. It is best to dispose your timer.

From http://msdn.microsoft.com/en-us/library/system.threading.timer.aspx :
"When a timer is no longer needed, use the Dispose method to free the resources held by the timer."
So if you want your timer to run until the end of the program, then you do not need to worry about it.

Garbage collection will cleanup up the Timer if you do not dispose of it. If the timer is in in .exe and the process will just be exited when the timer ends you really don't have to worry about. If your writing a library where the timer will be referenced you would want to dispose of it to free resources to make your library more efficient.

Calling Dispose() allows the cleanup of unmanaged resources used by your managed object before the garbage collector decides to cleanup the managed object, during which operation the unmanaged resources are also cleaned.
Calling Dispose() is usually about memory usage optimization, however, in some circumstances, not calling Dispose() will actually cause your software to not function properly. Eg: Because the number of ethernet ports is limited, not releasing them after usage may cause the system to run out of network ports. This is commonly known as "TCP/IP Port Exhaustion", and can occur when you do not call Dispose() on managed objects that use network resources (eg. WCF Clients).
As a general rule, it is always a smart idea to call Dispose() when you do no longer need any object which class implements IDisposable. (or use it in a using{} block).
In the example you provided, it seems like your timer variable is static, and bound to the main thread. It also seems like you are using your timer to the end of your program. So in this specific case, it really doesn't matter.

'Deadlock' with only one locked object?

I am having a problem with multi threading in C#.
I use an event to update a label in a form from another thread, for which I need to use the Invoke() command of course.
That part is also working fine.
However, the user can close the form and here the program can crash if the event is sent at an unfortunate time.
So, I thought I would simply override the Dispose() method of the form, set a boolean to true within locked code, and also check that boolean and invoke the event in locked code.
However, every time I close the form the program freezes completely.
Here are the mentioned parts of the code:
private object dispose_lock = new object();
private bool _disposed = false;
private void update(object sender, EventArgs e)
{
if (InvokeRequired)
{
EventHandler handler = new EventHandler(update);
lock (dispose_lock)
{
if (_disposed) return;
Invoke(handler); // this is where it crashes without using the lock
}
return;
}
label.Text = "blah";
}
protected override void Dispose(bool disposing)
{
eventfullObject.OnUpdate -= update;
lock (dispose_lock) // this is where it seems to freeze
{
_disposed = true; // this is never called
}
base.Dispose(disposing);
}
I hope anyone here has any idea what is wrong with this code.
Thank you in advance!

What you're not taking into account is that delegate passed to Invoke is called asynchronously on the UI thread. Calling Invoke posts a message to the forms message queue and is picked up some time later.
What happens is not:
UI Thread Background Thread
Call update()
take lock
Call Invoke()
Call update()
release lock
Call Dispose()
take lock
release lock
But instead:
UI Thread Background Thread
Call update()
take lock
Call Invoke()
block until UI Thread processes the message
Process messages
...
Dispose()
wait for lock ****** Deadlock! *****
...
Call update()
release lock
Because of this, the background thread can hold be holding the lock while the UI thread is trying to run Dispose
The solution is much simpler than what you tried. Because of the Invoke is posted asynchronously there is no need for a lock.
private bool _disposed = false;
private void update(object sender, EventArgs e)
{
if (InvokeRequired)
{
EventHandler handler = new EventHandler(update);
Invoke(handler);
return;
}
if (_disposed) return;
label.Text = "blah";
}
protected override void Dispose(bool disposing)
{
eventfullObject.OnUpdate -= update;
_disposed = true; // this is never called
base.Dispose(disposing);
}
The _disposed flag is only read or written on the UI thread so there is no need for locking. Now you call stack looks like:
UI Thread Background Thread
Call update()
take lock
Call Invoke()
block until UI Thread processes the message
Process messages
...
Dispose()
_disposed = true;
...
Call update()
_disposed is true so do nothing

One of the dangers of using Control.Invoke is that it could be disposed on the UI thread at an unfortunate time as you suggested. The most common way this occurs is when you have the following order of events
Background Thread: Queues a call back with Invoke
Foreground Thread: Dispose the Control on which the background called Invoke
Foreground Thread: Dequeues the call back on a disposed Control
In this scenario the Invoke will fail and cause an exception to be raised on the background thread. This is likely what was causing your application to crash in the first place.
With the new code though this causes a dead lock. The code will take the lock in step #1. Then the dispose happens in the UI at step #2 and it's waiting for the lock which won't be freed until after step #3 completes.
The easiest way to deal with this problem is to accept that Invoke is an operation that can and will fail hence needs a try / catch
private void update(object sender, EventArgs e)
{
if (InvokeRequired)
{
EventHandler handler = new EventHandler(update);
try
{
Invoke(handler);
}
catch (Exception)
{
// Control disposed while invoking. Nothing to do
}
return;
}
label.Text = "blah";
}

I really would go simple here. Instead of implementing tricky thread-safe code, I would simply catch the exception and do nothing if it fails.
Assuming it's a ObjectDisposedException:
try
{
this.Invoke(Invoke(handler));
}
catch (ObjectDisposedException)
{
// Won't do anything here as
// the object is not in the good state (diposed when closed)
// so we can't invoke.
}
It's simpler and pretty straightforward. If a comment specifies why you catch the exception, I think it's OK.

Why don't you just use BeginInvoke rather than Invoke - this won't block the background thread. It doesn't look like there is any specific reason why the background thread needs to wait for the UI update to occur from what you have shown

Another deadlocking scenario arises when calling Dispatcher.Invoke (in
a WPF application) or Control.Invoke (in a Windows Forms application)
while in possession of a lock. If the UI happens to be running another
method that’s waiting on the same lock, a deadlock will happen right
there. This can often be fixed simply by calling BeginInvoke instead
of Invoke. Alternatively, you can release your lock before calling
Invoke, although this won't work if your caller took out the lock. We
explain Invoke and BeginInvoke in Rich Client Applications and Thread
Affinity.
source: http://www.albahari.com/threading/part2.aspx

Just incase none of the other answers are the culprit, is there other code that terminates the thread that isn't posted? I'm thinking you might be using plain Threads and not a BackgroundWorker, and might have forgotten to set Thread.isBackround to true

IMO Dispose is too late...
I would recommend putting some code into FormClosing which is called before Dispose happens AFAIK.
For such a case I usually tend to use a different (atomic) pattern for your check - for example via the Interlocked class.
private long _runnable = 1;
private void update(object sender, EventArgs e)
{
if (InvokeRequired)
{
EventHandler handler = new EventHandler(update);
if (Interlocked.Read (ref _runnable) == 1) Invoke(handler);
return;
}
label.Text = "blah";
}
In FormClosing you just call Interlocked.Increment (ref _runnable) .