Multithreading in asp.net

Question

What kind of multi-threading issues do you have to be careful for in asp.net?

Answer 1

Programmatic Caching is one area which immediately comes to my mind. It is a great feature which needs to be used carefully. Since it is shared across requests, you have to put locks around it before updating it.

Another place I would check is any code accessing filesystem like writing to log files. If one request has a read-write lock on a file, other concurrent requests will error out if not handled properly.

Answer 2

One thing to watch out for at things that expire (I think httpContext does), if you are using it for operations that are "fire and forget" remember that all of a sudden if the asp.net cleanup code runs before your operation is done, you won't be able to access certain information.

Answer 3

Espo: Plagarism is frowned upon...

http://www.beansoftware.com/ASP.NET-Tutorials/Multithreading-Thread-Pool.aspx

You cut and pasted your answer from there.

Btw, I downvoted your answer for the following reasons:

• I've noticed a trend in your answers with them just being cut and pasted from google searches. While this not bad, it doesn't really stimulate the community.
• Your answer did not apply to the question at hand. You pasted some generic info about multithreading that was applicable to any multithreaded app, not ASP.NET in specific.
• Finally, you did not originally cite your source. Thank you for correcting that with the edit. I do not like people who plagiarize.

Answer 4

If this is for a web service, you should definitely consider thread pooling. Too many threads will bring your application to a grinding halt because they will eventually start competing for CPU time.

Is this for file or network IO? If so, you should also consider using asynchronous IO. It can be a bit more of a pain to program, but you don't have to worry about spawning off too many threads at once.

Answer 5

It's risky to spawn threads from the code-behind of an ASP.NET page, because the worker process will get recycled occasionally and your thread will die.

If you need to kick off long-running processes as a result of user actions on web pages, your best bet is to drop a message off in MSMQ and have a separate background service monitoring the queue. The service could take as long as it wants to accomplish the task, and the web page would be finished with its work almost immediately. You could accomplish the same thing with an asynch call to a web method, but don't rely on getting the response when the web method is finished working. From code-behind, it needs to be a quick fire-and-forget.

Answer 6

Isn't there a Limit of 25 Total Threads in the IIS Configuration? At least in IIS 6 i believe. If you exceed that limit, interesting things (read: loooooooong response times) may happen.