C# Communication between threads

Question

I am using .NET 3.5 and am trying to wrap my head around a problem (not being a supreme threading expert bear with me).

I have a windows service which has a very intensive process that is always running, I have put this process onto a separate thread so that the main thread of my service can handle operational tasks - i.e., service audit cycles, handling configuration changes, etc, etc.

I'm starting the thread via the typical ThreadStart to a method which kicks the process off - call it workerthread.

On this workerthread I am sending data to another server, as is expected the server reboots every now and again and connection is lost and I need to re-establish the connection (I am notified by the lost of connection via an event). From here I do my reconnect logic and I am back in and running, however what I easily started to notice to happen was that I was creating this worker thread over and over again each time (not what I want).

Now I could kill the workerthread when I lose the connection and start a new one but this seems like a waste of resources.

What I really want to do, is marshal the call (i.e., my thread start method) back to the thread that is still in memory although not doing anything.

Please post any examples or docs you have that would be of use.

Thanks.

Answer 1

You should avoid killing the worker thread. When you forcibly kill a Win32 thread, not all of its resources are fully recovered. I believe the reserved virtual address space (or is it the root page?) for the thread stack is not recovered when a Win32 thread is killed. It may not be much, but in a long-running server service process, it will add up over time and eventually bring down your service.

If the thread is allowed to exit its threadproc to terminate normally, all the resources are recovered.

If the background thread will be running continuously (not sleeping), you could just use a global boolean flag to communicate state between the main thread and the background thread. As long as the background thread checks this global flag periodically. If the flag is set, the thread can shut itself down cleanly and exit. No need for locking semantics if the main thread is the only writer and the background thread only reads the flag value.

When the background thread loses the connection to the server that it's sending data to, why doesn't it perform the reconnect on its own? It's not clear to me why the main thread needs to tear down the background thread to start another.