Does multithreading make sense in asp.net?

In winforms development you may create a BackgroundWorker to avoid locking the UI on a long running process. In ASP.NET a POST/GET basically freezes until completion. I don't see how adding a Thread would be of any benefit to this process. Maybe if the Thread would speed completion (say on a multi-core server) it could help speed things up. 开发者_JAVA技巧

In the general sense I could use AJAX to make long calls without causing a "freeze" of the web page. In this sense AJAX can be thought of as a substitute for threading.

Is that it? Is threading pretty much useless on ASP.NET?

---

Multithreading can make requests faster if:

1. Each web request's work can be broken down into multiple tasks that can run in parallel
2. Each of those tasks is very CPU intensive (CPU bound), or you have multiple I/O bound tasks on different I/O paths (see comments)
3. You can implement them using fork/join parallelism.

In that case, you can indeed use multithreading in ASP.NET. A common mistake that people make is to spawn off threads and then not wait for them to complete- for instance "I am going to respond to the user while logging their purchase to the database on a background thread. This is always a bad idea, because IIS can and will recycle the Application Pool that your website is running in, and those background threads might be silently aborted.

---

Threading can be useful in server side programming if you need to return a response and don't want to tie up the server thread, in particular for long running processes that would cause the request to time out.

---

A thread may be used for actions that last longer than the lifetime of the page request, so yes, it makes sense.

An example would be a thread that spins up a process to encode video. Since this can take some time, the client can be updated later with the encoding progress via AJAX or Comet, or any other number of mechanisms.

---

It depends on the workload and the use case. Request/Response systems are best served by executing them asynchrounously on the client side.

If the workload on the server warrents threading, the work can be done in parallel but each thread should be joined at the end to return a single response.

The bottom line is that if the data you are getting can be loaded faster in parallel, do it, otherwise use async (ajax) calls from the client to prevent the user interface from blocking

---

Here is a concrete example of how you can still use multiple threads with the ASP.NET programming model. The example assumes that you can break down the tasks required to load a page into independent work items. You then process the work items in parallel and wait for them to complete. I am using the Task Parallel Library to abstract away the explicit creation of threads, but the result is all the same. The ASP.NET programming certainly can accomodate and benefit from a multithreaded design.

private void Page_Load(object sender, EventArgs e)
{
  ICollection<WorkItem> workitems = GetWorkItems();

  Parallel.ForEach(workitems,
    (item) =>
    {
      ProcessWorkItem(item);
    });

  // Now that we have all of our work items completed we can continue loading the page.
}

---

I wouldn't go so far as to say threading is useless in ASP.NET, but it's definitely a different model. For resource requests (page requests) in general, the threading is handled by the system. That is, Request A from User 1 can take longer than Request B from User 2 and the latter isn't inconvenienced by the former. Applying that concept to AJAX requests as you suggest and the entire model becomes multi-threaded by default and scales to whatever the hardware can handle.

Spawning a thread can be useful if, for some reason, a request must spawn some long-running process and needs to respond to the user before the process completes. Generally non-live processes should be re-factored out of the web application and placed into their own back-end service. But it's not entirely unheard-of for a page request to spawn a thread that's expected to do something in the background for a few minutes so that the browser isn't waiting the whole time (and likely timing out).