There are two main ways of multi-threading which .NET encourages:
To start your own threads with ThreadStart delegates, you should create a new thread "manually" for long-running tasks.
Using the ThreadPool class either directly (using ThreadPool.QueueUserWorkItem) or indirectly using asynchronous methods (such as Stream.BeginRead, or calling BeginInvoke on any delegate).
Use the thread pool only for brief jobs.
Benefits of using the Thread Pool.
Benefits of using the Thread Pool.
The benefits of using a Thread Pool are:
Thread creation and destruction overhead is negated,
Better performance and better system stability.
It is better to use a thread pool in cases where the number of threads is very large.
"ASP.NET does not rely on SQL Server or LDAP for session management. Basically we provide two new additional features:
1.) Cookieless Session: This is where we "munge" the sessionid into URLs as opposed to client-side cookies to keep track of SessionIDs (enabling you to now use session state even with browsers that have cookie support disabled). We automatically do the munging for you (no code changes required) to make this happen for both static and dynamic content (so you can link off to a static html page which then in turn links off to another dynamic page -- and the session is maintained).
2.) External Session State Support. This is where we store session values into an external state store instead of the ASP.NET worker process. This guaretees that state is stored accross worker process restarts (providing great reliability) as well as accross multiple machines (providing built-in web farm support). We ship support for two session stores out of the box: 1) the "ASP.NET state store" which is a dedicated NT Service that can run on any box -- and which ships with the ASP.NET bits. 2) support for storing session data directly into SQL Server. This later option is more scalable -- but does require you to buy SQL Server in order to make it work.
"Note that the above two state options are completely orthoganal from each other -- ie: you can use them together or separately. Also, our external state store support is pluggable -- meaning that we expect other third parties (as well as people like MS Commerce Server) to plug in their own store support into the model.
"With regard to performance, we are *much* faster than than existing pre-ASP.NET state solutions when doing out of proc state. We are leveraging ASP.NET's new MTA based thread pool to do async read/write operations that enable us to avoid blocking worker threads when retrieving and updating the state (instead using iocompletions to reuse threads). This should improve system throughput significantly and was not possible before with ASP (since it used an STA thread pool and as such couldn't do async operations)."