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 int

Answer 1

The BackgroundWorker is a bit slower than using plain threads, but it has the option of supporting the CancelAsync method.
Basically, BackgroundWorker is a wrapper around a worker thread with some extra options and events.

The CancelAsync method only works when WorkerSupportsCancellation is set.
When CancelAsync is called, CancellationPending is set.
The worker thread should periodically check CancellationPending to see if needs to quit prematurely.

--jeroen

Answer 2

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.

Answer 3

Have you considered a BackgroundWorker?

From what I understand, you just have a single thread that's doing work, unless the need arises where you have to cancel it's processing.

Answer 4

I would kill (but end gracefully if possible) the worker thread anyway. Everything gets garbage-collected, and you can start from scratch.

How often does this server reboot happen? If it happens often enough for resources to be a problem, it's probably happening too often.

Answer 5

You can use the Singleton pattern. In your case, make the connection a static object. Both threads can access the object, which means construct it and use it.

The main thread could construct it whenever required, and the worker thread access it whenever it is available.

Answer 6

Call the method using ThreadPool.QueueUserWorkItem instead. This method grabs a thread from the thread pool and kicks off a method. It appears to be ideal for the task of starting a method on another thread.

Also, when you say "typical ThreadStart" do you mean you're creating and starting a new Thread with a ThreadStart parameter, or you're creating a ThreadStart and calling Invoke on it?