Tasks vs ThreadPool

Please take a look at ParallelOptions.MaxDegreeOfParallelism for Tasks.

I would advise you to use Tasks, because they provide a higher level abstraction than the ThreadPool.

A very good read on the topic can be found here. Really, a must-have book and it's free on top of that :)

In TPL you can use the WithDegreeOfParallelism on a ParallelEnumerable or ParallelOptions.MaxDegreeOfParallism

There is also the CountdownEvent which may be a better option if you are just using custom threads or tasks.

In the ThreadPool, when you use SetMaxThreads its global for the AppDomain so you could potentially be limiting unrelated code unnecessarily.

You cannot set the number of worker threads or the number of I/O completion threads to a number smaller than the number of processors in the computer.

If the common language runtime is hosted, for example by Internet Information Services (IIS) or SQL Server, the host can limit or prevent changes to the thread pool size.

Use caution when changing the maximum number of threads in the thread pool. While your code might benefit, the changes might have an adverse effect on code libraries you use.

Setting the thread pool size too large can cause performance problems. If too many threads are executing at the same time, the task switching overhead becomes a significant factor.

I agree with the other answer that you should use TPL over the ThreadPool as its a better abstraction of multi-threading, but its possible to accomplish what you want in both.

In this article on msdn, they explain why they recommend Tasks instead of ThreadPool for Parallelism.