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.

Dispose Unmanaged Resources in Thread

I have a class that uses unmanaged resources in a thread, it can also go to sleep when not in use. I am implementing dispose for it, please see example code below (noting it is a dumbed down version of my app). I added while(TheThread.IsAlive()); as disposed could be set to true before DestroySomeUnmangedResouces() has executed. I don't think what I have done is correct so would be grateful if someone could suggest a better model.
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
//managed
}
//unmanged
_stopTheThread = true;
startTheThreadEvent.Set();
while(TheThread.IsAlive());
}
disposed = true;
}
private void TheThread()
{
while (!_stopTheThread)
{
if (state == State.Stopped)
{
// wait till a start occurs
startTheThreadEvent.WaitOne();
}
switch (state)
{
case Init:
CreateSomeUnmangedResouces();
break;
case Run:
DoStuffWithUnmangedResouces();
break;
case Stop:
DestroySomeUnmangedResouces();
break;
} // switch
}
// Release unmanaged resources when component is disposed
DestroySomeUnmangedResouces();
}

You seem to want to wait until your worker thread has exited. For this you can simply use Thread.Join() which will block until your thread has exited.
Currently you are eating 100% CPU on your wait thread because you do poll if the worker thread is still alive. A less resource intensive variant is a throttled polling where you sleep between your checks at least a timeslice (15ms).
But the by far best approach is to wait for a synchronisation primitive which gets signaled and wakes up your thread when a condtion becomes true. Thead.Join is therefore the way to go.

private readonly ManualResetEvent _stopEvent = new ManualResetEvent(false);
private readonly ManualResetEvent _threadStoppedEvent = new ManualResetEvent(false);
private bool disposed;
private int checkInterval = 10;//ms
protected virtual void Dispose(bool disposing)
{
if (!disposed)
{
if (disposing)
{
//managed
}
//unmanged
_stopEvent.Set();
_threadStoppedEvent.WaitOne();
}
disposed = true;
}
private void TheThread()
{
CreateSomeUnmangedResouces();
while (!_stopEvent.WaitOne(checkInterval))
{
DoStuffWithUnmangedResouces();
}
DestroySomeUnmangedResouces();
_threadStoppedEvent.Set();
}
Or you can use Thread.Join() instead of _threadStoppedEvent if your thread isn't background

The caller calling dispose should mop up the thread - the best way is to call Join on it as Alois has suggested. Once the thread has joined, then you can destroy the unmanaged resources which will now happen on the callers thread. E.g.:
protected virtual void
Dispose
(bool disposing)
{
if (!disposed)
{
if (disposing)
{
if(TheThread != null)
{
// send a signal to stop the thread.
_stopTheThread = true;
startTheThreadEvent.Set();
// Join the thread - we could timeout here but it should be the
// responsibility of the thread owner to ensure it exits
// If this is hanging then the owning object hasn't terminated
// its thread
TheThread.Join();
TheThread = null;
}
}
// Now deal with unmanaged resources!
DestroySomeUnmangedResouces();
}
disposed = true;
}
One drawback of this approach is that we are assuming the thread will eventually exit. It could hang, meaning the signals to stop the thread was not enough. There are overloads for Join which include timeouts, which could be used to prevent hanging the calling thread (see comment in code sample above).

If a running thread holds a direct or indirect strong reference to an object, such reference will prevent the object from becoming eligible for garbage collection. There's thus not really any reason to have a finalizer on such an object.
If, however, the thread will only be relevant as long as a reference some other particular object is held by something other than the thread, it may be useful for the thread to hold a WeakReference to that other object, and shut itself down if that other object goes out of scope. This shutdown could be accomplished either by having the thread periodically check the IsAlive property of the WeakReference, or by having the other object include a finalizer which would signal the thread to shut down. Although periodic polling for such things is in some sense icky, and using a finalizer could somewhat hasten the shutdown of the thread, I think polling is probably still better. While it's possible for a finalizer to notify a thread that it should do something, and there are times when doing so may be appropriate, in general the fact that an object was finalized meant that nobody was overly concerned about prompt cleanup. Adding another few seconds' delay before the thread shuts down probably won't hurt anything.

Use Dispose() or finalizer to clean up managed threads?

Suppose I have a message pump class in C++0x like the following (note, SynchronizedQueue is a queue of function<void()> and when you call receive() on the queue and it is empty, it blocks the calling thread until there is an item to return):
class MessagePump
{
private:
bool done_;
Thread* thread_;
SynchronizedQueue queue_;
void Run()
{
while (!done)
{
function<void()> msg = queue_.receive();
msg();
}
}
public:
MessagePump():
done_(false)
{
thread_ = new thread ([=] { this->Run(); } ) );
}
~MessagePump()
{
Send( [&]{ done = true; } );
thread_->join();
}
void Send (function<void()> msg)
{
queue_.send(msg);
}
};
I have converted this class into C#, but I have a question for the code in the destructor. According to the IDisposable pattern, I should only provide a Dispose() method in order to free managed and unmanaged resources.
Should I put the C++ destructor code into:
A custom CleanUp() method that the client needs to call when application is exiting? What if the client forgets?
A Dispose() method of IDisposable so that the client can also call it? But again, what if the client forgets?
Inside the C# finalizer method so it will always execute? I read that if you do not have any unmanaged resources, you shouldn't include a finalizer method because it hurts performance.
Nowhere? Just ignore marking the done_ flag and just let GC handle it naturally since the Thread object is a managed resource? Will the thread be forcibly aborted in this way?
I have also found out that if I don't mark the message pump thread created inside the constructor as a background thread, my MessagePump object never gets GC'ed and the application just hangs when it exits. What's the reason for this?

At a high level, I would just suggest using the .NET thread pool (System.Threading.ThreadPool) for queueing and executing multiple work items, since that's what it was designed for (assuming the work items are allowed to be executed asynchronously). Specifically, check out the QueueUserWorkItem method.
To answer your questions, though:
Should I put the C++ destructor code into:
A custom CleanUp() method that the client needs to call when application is exiting? What if the client forgets?
A Dispose() method of IDisposable so that the client can also call it? But again, what if the client forgets?
Always prefer implementing IDisposable over custom CleanUp methods (in the BCL, some Stream classes have a Close method that is really just an alias for Dispose). The IDisposable pattern is the way to do deterministic cleanup with C#. The client forgetting to call Dispose is always an issue, but this can often be detected by static analysis tools (e.g. FxCop).
Inside the C# finalizer method so it will always execute? I read that if you do not have any unmanaged resources, you shouldn't include a finalizer method because it hurts performance.
Finalizers are not guaranteed to execute (see this article), so a correct program cannot assume that they will execute. Performance won't be an issue here. I'm guessing you'll have a couple of MessagePump objects at most, so the cost of having a finalizer is insubstantial.
Nowhere? Just ignore marking the done_ flag and just let GC handle it naturally since the Thread object is a managed resource? Will the thread be forcibly aborted in this way?
The thread is managed by the CLR and will be properly cleaned-up. If the thread returns from its entry point (Run here), it won't be aborted, it will just exit cleanly. This code still needs to go somewhere though, so I would provide explicit cleanup through IDisposable.
I have also found out that if I don't mark the message pump thread created inside the constructor as a background thread, my MessagePump object never gets GC'ed and the application just hangs when it exits. What's the reason for this?
A .NET application runs until all foreground (non-background) threads terminate. So if you don't mark your MessagePump thread as a background thread, it will keep your application alive while it runs. If some object still references your MessagePump, then the MessagePump will never be GC'ed or finalized. Referencing the article above again, though, you can't assume that the finalizer will ever run.

One pattern that may be helpful is to have outside users of the message pump hold strong references to a "STILL IN USE" flag object to which the pump itself only holds a weak weak reference (which will be invalidated as soon as the object's "STILL IN USE" becomes eligible for finalization). The finalizer for this object might be able to send the message pump a message, and the message pump could check the continued validity of its weak reference; if it has become invalid, the message pump could then shut down.
Note that one common difficulty with message pumps is that the thread that operates them will tend to keep alive a lot of objects which are used by nothing but that thread. One needs a separate object, to which the thread will avoid keeping a strong reference, to ensure that things can get cleaned up.

Should a class with a Thread member implement IDisposable?

Let's say I have this class Logger that is logging strings in a low-priority worker thread, which isn't a background thread. Strings are queued in Logger.WriteLine and munched in Logger.Worker. No queued strings are allowed to be lost. Roughly like this (implementation, locking, synchronizing, etc. omitted for clarity):
public class Logger
{
private Thread workerThread;
private Queue<String> logTexts;
private AutoResetEvent logEvent;
private AutoResetEvent stopEvent;
// Locks the queue, adds the text to it and sets the log event.
public void WriteLine(String text);
// Sets the stop event without waiting for the thread to stop.
public void AsyncStop();
// Waits for any of the log event or stop event to be signalled.
// If log event is set, it locks the queue, grabs the texts and logs them.
// If stop event is set, it exits the function and the thread.
private void Worker();
}
Since the worker thread is a foreground thread, I have to be able to deterministically stop it if the process should be able to finish.
Question: Is the general recommendation in this scenario to let Logger implement IDisposable and stop the worker thread in Dispose()? Something like this:
public class Logger : IDisposable
{
...
public void Dispose()
{
AsyncStop();
this.workerThread.Join();
}
}
Or are there better ways of handling it?

That would certainly work - a Thread qualifies as a resource, etc. The main benefit of IDisposable comes from the using statement, so it really depends on whether the typical use for the owner of the object is to use the object for a duration of time in a single method - i.e.
void Foo() {
...
using(var obj = YourObject()) {
... some loop?
}
...
}
If that makes sense (perhaps a work pump), then fine; IDisposable would be helpful for the case when an exception is thrown. If that isn't the typical use then other than highlighting that it needs some kind of cleanup, it isn't quite so helpful.

That's usually the best, as long as you have a deterministic way to dispose the logger (using block on the main part of the app, try/finally, shutdown handler, etc).

It may be a good idea to have the thread hold a WeakReference to the managing object, and periodically check to ensure that it still exists. In theory, you could use a finalizer to nudge your thread (note that the finalizer, unlike the Dispose, should not do a Thread.Join), but it may be a good idea to allow for the possibility of the finalizer failing.

You should be aware that if user doesn't call Dispose manually (via using or otherwise) application will never exit, as Thread object will hold strong reference to your Logger. Answer provided by supercat is much better general solution to this problem.