Develop Reference

What is the C#/.NET 4.0+ way to implement a cancellable background thread?

Before .NET 4.0, my understanding is that if one wanted to start a thread to do some work which could be cancelled, one would start a BackgroundWorker. .NET 4 brought about the TAP model, and a whole bunch of new async and threading stuff. Is the BackgroundWorker still the way to do it?

In modern code, I'd recommend using Task.Run with a CancellationToken. The BackgroundWorker style of cancellation is rather convoluted in comparison: it requires the DoWork delegate to monitor its own BackgroundWorker instance, and treats a cancellation request as a boolean rather than an exception.
I have a blog post that goes into more detail.

Note that async (and the corollary keyword await) are both .NET 4.5, and not available in 4.0. If you want to use Tasks at all, I highly recommend upgrading to .NET 4.5. Even in 4.0, however, there areseveral overloaded methods which optionally take CancellationTokens that can be used to cancel running work.
EDIT: As pointed out in comments, there are ways to get async/await on .NET 4.0 - you just need less work and have more library support in 4.5. Not something I would recommend without a dire need for XP support.
As of .NET 4.5, the BackgroundWorker class is not marked as [Obsolete], so there's no reason you shouldn't continue using it directly.
The Thread class contains a direct .Abort() method, which can be used to create a worker which can be cancelled. Note that this abort happens via throwing a ThreadAbortException in the running thread, thus allowing a catch statement to still perform any cleanup in the event of thread abortion.

Is it fine to use tasks and thread-pool together?

After reading how the thread pool and tasks work in this article I came up with this question -
If I have a complex program in which some modules use tasks and some use thread pool, is it possible that there will be some scheduling problems due to the different uses?

Task are often implemented using the thread pool (one can of course also have tasks using other types of schedulers that give different behavior, but this is the default). In terms of the actual code being executed (assuming your tasks are representing delegates being run) there really isn't much difference.
Tasks are simply creating a wrapper around that thread pool call to provide additional functionality when it comes to gather information about, and processing the results of, that asynchronous operation. If you want to leverage that additional functionality then use tasks. If you have no need to use it in some particular context, there's nothing wrong with using the thread pool directly.
Mix the two, so long as you don't have trouble getting what you want out of the results of those operations, is not a problem at all.

No. And there actually isn't much in the way of memory or performance inefficiencies when mixing approaches; by default tasks use the same thread pool that thread pool threads use.
The only significant disadvantage of mixing both is lack of consistency in your codebase. If you were to pick one, I would use TPL since it is has a rich API for handling many aspects of multi-threading and takes advantage of async/await language features.
Since your usage is divided down module lines, you don't have much to worry about.

No, there wouldn't be problems - you just would be inefficient in doing both. use what is really needed and stick with the pattern. Remember to be sure that you make your app MT Safe also especially if you are accessing the same resources/variables etc... from different threads, regardless of which threading algorithm you use.

There shouldn't be any scheduling problems as such, but of course it's better to use Tasks and let the Framework decide what to do with the scheduled work. In the current version of the framework (4.5) the work will be queued through the ThreadPool unless the LongRunning option is used, but this behaviour may change in future of course.
Verdict: Mixing Tasks and ThreadPool isn't a problem, but for new applications it's recommended to use Tasks instead of queueing work items directly on the ThreadPool (one reason for that is ThreadPool isn't available in Windows 8 Runtime (Modern UI apps).

Non-Blocking Threading

I am re-factoring a C# project that is used by several full-sized applications. This class interacts with hardware and often takes hundreds of milliseconds or more to execute some commands. In many cases, I am replacing Thread.Wait() calls that the previous programmer wrote with ThreadPool calls to perform these actions.
Now, some of the functions this project provides to the several projects using it take hundreds of milliseconds or more to execute and return a value to the calling program that the program must use. My question is whether or not there is some mechanism that I may use within this project to make these calls execute and return on some thread other than the main thread? In other words, I want to make these methods non-blocking from the perspective of this project, rather than require other applications using these functions to place calls in a separate thread.
Thanks

In other words, I want to make these methods non-blocking from the perspective of this project, rather than require other applications using these functions to place calls in a separate thread.
In general, the best approach is often to return a Task<T> in this type of scenario. This allows the caller to block if necessary, or use the new await and async keywords to cleanly coordinate with your library, without blocking or forcing them to move to a separate thread.

If you are using .net 4.5 you can use Task.Run to execute the slow operations on a separate thread and then ConfigureAwait(false) to not execute on the main thread once they return.
Task.Run(() => <slow operatoion).ConfigureAwait(false);

Not knowing what version of the framework you're using, have a look at the begin/end async pattern. You should look at changing the API for the project to implement it.
http://msdn.microsoft.com/en-us/library/ms228963.aspx

i worked on similar stuff ... i would suggest you to use 'select' instead of using threading.... look at this ... if it helps you
http://www.kegel.com/c10k.html

Dispatcher, BackgroundWorker or Parallel?

As part of trying to learn C#, I'm writing a small app that goes through a list of proxies. For each proxy it will create an httpwebrequest to a proxytest.php which prints generic data about a given proxy (or doesn't, in which case the proxy is discarded)
Clearly the webrequest code needs to run in a separate thread - especially since I'm planning on going through rather large lists. But even on a separate thread, going through 5,000 proxies will take forever, so I think this means I am to create multiple threads (correct me if I'm wrong)
I looked through MSDN and random threading tutorials and there's several different classes available. What's the difference between dispatcher, backgroundworker and parallel? I was given this snippet:
Parallel.ForEach(URLsList, new ParallelOptions() { MaxDegreeOfParallelism = S0 }, (m, i, j) =>
{
string[] UP = m.Split('|');
string User = UP[0];
string Pass = UP[1];
// make call here
}
I'm not really sure how it's different than something like starting 5 separate background workers would do.
So what are the differences between those three and what would be a good (easy) approach to this problem?
Thanks

The Dispatcher is an object that models the message loop of WPF applications. If that doesn't mean anything to you then forget you ever heard of it.
BackgroundWorker is a convenience class over a thread that is part of the managed thread pool. It exists to provide some commonly requested functionality over manually assigning work to the thread pool with ThreadPool.QueueUserWorkItem.
The Thread class is very much like using the managed thread pool, with the difference being that you are in absolute control of the thread's lifetime (on the flip side, it's worse than using the thread pool if you intend to launch lots of short tasks).
The Task Parallel Library (TPL) (i.e. using Parallel.ForEach) would indeed be the best approach, since it not only takes care of assigning work units to a number of threads (from the managed thread pool) but it will also automatically divide the work units among those threads.

I would say use the task parallel library. It is a new library around all the manual threading code you will have to write otherwise.
The Task Parallel Library (TPL) is a collection of new classes specifically designed to make it easier and more efficient to execute very fine-grained parallel workloads on modern hardware. TPL has been available separately as a CTP for some time now, and was included in the Visual Studio 2010 CTP, but in those releases it was built on its own dedicated work scheduler. For Beta 1 of CLR 4.0, the default scheduler for TPL will be the CLR thread pool, which allows TPL-style workloads to “play nice” with existing, QUWI-based code, and allows us to reuse much of the underlying technology in the thread pool - in particular, the thread-injection algorithm, which we will discuss in a future post.
from
http://blogs.msdn.com/b/ericeil/archive/2009/04/23/clr-4-0-threadpool-improvements-part-1.aspx
I found working with this new 4 library really easy. This blog is showing the old BackgroundWorker way of doing things and the new Task way of doing things.
http://nitoprograms.blogspot.com/2010/06/reporting-progress-from-tasks.html

Is there a Thread Pool for Silverlight with a maximum number of threads?

I have created a renderer in Silverlight/C#. Currently I'm using System.Threading.ThreadPool to schedule rendering of tiles in parallel. This works well right now, but I would like to limit the number of threads used.
Since this runs on Silverlight there are a couple of restrictions:
If I call ThreadPool.SetMaxThreads the application crashes as documented.
There is no Task Parallel Library
I see a few options:
Find an OSS/third party Thread Pool
Implement my own Thread Pool (I'd rather not)
Use Rx (which I do in other places)
Are there any tested alternative Thread Pools that work with Silverlight out there?
Or can anyone come up with a Rx expression that spawns a limited number of threads and queue work on these?

If you're using Rx, check out:
https://github.com/xpaulbettsx/ReactiveUI/blob/master/ReactiveUI/ObservableAsyncMRUCache.cs
(Copying this one file into your app should be pretty easy, just nuke the this.Log() lines and the IEnableLogger interface)
Using it is pretty easy, just change your SelectMany to CachedSelectMany:
someArray.ToObservable()
.CachedSelectMany(webService)
.Subscribe(x => /* do stuff */);

If you use Rx then it seems like you could quite easily write your own implementation of IScheduler. This could just apply a simple semaphore and then pass the work on to the ThreadPool. With this approach you get to leaverage the ThreadPool, allow for testing as you are coding against an interface and you will also have good seams for testing.
Further more, as you have written this yourself, you could actually use a small-ish (<10)set of Threads that you manage yourself (instead of the threadpool)so you can avoid ThreadPool starvation.

Check out Ami Bar's SmartThreadPool. It's got a ton of features missing from the default .NET threadpool, allows you to set a MaxThreads property per threadpool instance, and supports Silverlight.