When to use System.Threading.ThreadPool and when one of the many custom thread pools?

Question

I'm working on creating an async handler for ASP.NET that will execute a slow stored procedure. I think I understand that to gain additional throughput on a mixed load of slow and fast pages, the slow page needs to be executed on a thread pool separate from the one the ASP.NET uses, otherwise the async pattern will cause double the number of scarce threads to be used (correct me if I'm wrong).

So I have found System.Threading.ThreadPool - it looks like it should do the trick, but...

The various tutorials on the net such as this one which uses this custom pool, the one in John Skeet's MiscUtils, and the custom thread pool referenced in this tutorial about async patterns.

System.Threading.ThreadPool has existed since 1.1 - why do people routinely feel the need to write a brand new one? Should I avoid using System.Threading.ThreadPool?

I'm a rank beginner when it comes to threading, so go easy on the undefined jargon.

UPDATE. The stored procedure to be executed will not necessarily be MS-SQL and will not necessarily be able to use a built-in async method such as BeginExecuteNonQuery().

Comestible

My feeling is that you should use the asynchronous pages to achieve this. msdn.microsoft.com/en-us/magazine/cc163725.aspx Reinventing a threading mechanism for something like a stored procedure call is going to be counter productive in my opinion. Using a supported best practice is best. I would recommend using custom threading patterns only for specific patterns that demand them (like COM apartments). – Urbane

You should not need to use a separate thread pool (than ASP.NET) as when your stored procedure is I/O bound the thread executing it will be used for other requests. #3288772 – Urbane

@Urbane the article you referenced more or less agrees with the accepted answer, esp the final paragraph. (i.e. either use built in asynch methods such as BeginExecuteNonQuery, which don't use ASP.NETs threads or use a new thread/custom pool) – Comestible

Answer 1

Here's what I found on the topic. Why you shouldn't use ThreadPool in ASP.NET http://madskristensen.net/post/Done28099t-use-the-ThreadPool-in-ASPNET.aspx. It's quite old but I don't think it has changed that much. Or correct me if I'm wrong.

Using the System.Threading.ThreadPool or a custom delegate and calling its BeginInvoke offer a quick way to fire off worker threads for your application. But unfortunately, they hurt the overall performance of your application since they consume threads from the same pool used by ASP.NET to handle HTTP requests.

Using custom threads with the aid of System.Threading.Thread class should solve the problem as the threads created are not part of your application's pool.

Aryanize