Restarting a thread with different inputs

First off - apologies if this or a similar question has been asked before. It feels like it should have been, but I've been unable to find one.

I have a third party assembly with a method I'm calling, this method has parameters taking a list of objects (in concept, not List<object>) and returns a result after a potentially long running algorithm.

I call this method on a different thread to preserve UI responsiveness. And it gets called quite regularly and with a different list of values. This means that it's often running when I want to re-run it. The problem I have is that the creation of the new thread is quite naive so it fires off a new one each time - this results in multiple threads running with different input parameters. What I actually want to happen is for any existing threads to die as I'm no longer interested in their output.

I'm not very familiar with multi threading best practises so I would really like some suggestions on the best way to approach this problem.

(I'm using 3.5 so no TPL)

EDIT I cracked out Reflector to see what was going on inside and a lot of the code is marked protected so I'm pretty certain I can inherit 开发者_Python百科and wrap the call in a check to quit early as per the answers below.

You could treat this as a Producer/Consumer pattern.

Instead of starting a Thread, post (produce) a new Datapacket.

The Consuming Thread should monitor the queue and start on a new packet when it arrives.

Note that stopping the Thread is your main issue here. Don't even look at Thread.Abort(). You need to build that logic into the thread-code.

You can't restart a single thread. What you could do is maintain a queue of jobs. Then, when executing a job you could check periodically whether there are any newer jobs - if there are, abandon the current one and start the new one. This is easiest when each "job" consists of performing many tasks (e.g. the same task on multiple inputs within the job, or various different steps). In that case, just check before you start each task.

A couple questions have to be asked about this third-party code:

• Does it write to persistent storage during processing? i.e. files or to a database
• If it writes to persistent storage, does that affect future runs? (probably not, as you've been able to run in parallel)

If the answer to both questions is yes, you're in a difficult situation. It's hard to imagine any way of restoring the persistent storage to a consistent state which wouldn't be more expensive than just letting the algorithm run to completion. (Although if long-running means more than a couple minutes, doing a VM clone and transferring the data to it might be less work.)

If either question is no, you can abort processing. But the smallest unit which Windows allows you to cleanly abort is a process. You'll have to spawn a worker process to perform the calculation. The most straightforward way is to build a TCP service (.NET comes with tools for this -- WCF). If the third-party code only reads its input data, you can use tools like shared memory to reduce the cost of transferring data to this subprocess.