Moderator_MSDNIndia: Today we have with us Kumar Gaurav Khanna, who is a Microsoft MVP

Moderator_MSDNIndia: he will answer your questions on Threading and Thread Pools in .NET

Moderator_MSDNIndia: Over to you Kumar, you might want to start with an intro on threading in .NET

Kumar: Thank you Deepak..

Kumar: I will commence with a very brief overview of what threading is all about..

Kumar: since all of you must already be aware of it...but here's for the completion sake..

Kumar: that said, we take a look at the various threading supports built into .NET, see it from the eyes of Rotor and then I shall answer your queries..

Kumar: To start with..

Kumar: Win32 defined processes...environments which executed a piece of code termed as the thread. Win32 supported concurrent execution of one or more threads and it still does - only this is a simulation on a uni-processor system, while its true multitasking on a multi-processor system.

Kumar: Why we use threads? Well..

Kumar: to make our applications more responsive..

Kumar: to make our applications service multiple clients (e.g. web servers)

Kumar: to make our applications do more in less time..

Kumar: of course, the last point warrants the fact that your code must have a

Kumar: high degree of parallelism in it. For a code which is 90% serial... and 10% parallel..

Kumar: multi-threading will not be of much help. In fact, one should be very careful while implementing multi-threaded apps on uni-proc systems... since your implementation of multiple threads can make the very threads compete against each other for CPU and in fact make your app less efficient!

Kumar: That said.. lets take a turn into .NET..

Kumar: In .NET, whenever a piece of code executes, it does so in what is called an AppDomain. AppDomain can be visualized as the .NET version of a Win32 process, but the difference being that its a Win32 process which contains one or more AppDomains.

Kumar: And it is within one of these AppDomains that your code executes on a thread. There's no one-to-one correspondence between the Win32 process and a .NET AppDomain for the reason stated above. However, they are quite similar to each other in the context of how COM Apartments live in Win32 processes.

Kumar: The noticeable thing about .NET threading is that unlike AppDomain which is a .NET construct and has no physical existence in the Win32 world, there is currently a one-to-one correspondence between a Win32 thread and the thread your .NET application creates.

Kumar: Thus, any threads created by your application are actually mapping to underlying Win32 Threads which live in the Win32 Process and hence, are used by the .NET Runtime to service *all AppDomains* in the given Win32 process.

Kumar: A Thread in .NET will never be bound to a given AppDomain from the context of servicing the code in the AppDomains, and this concept has been made so flexible that if you look into Rotor sources in future this mapping can be easily changed to one or more physical threads corresponding to a .NET thread, making the concept quite similar to a COM+ activity

Kumar: Thus, the idea of this insight is to understand how threads will be managed by the runtime for the processing of your application, and we have just seen one difference: that threads can be used to service any AppDomain within a Process.

Kumar: So, the next question is - When should we use threads?

Kumar: A typical situation would be when you are in the process of implementing - a server side application, like an email server, to process multiple incoming client requests - particularly when *you want to control the thread lifetime* and manage it!

Kumar: So, is it possible for us to have a multithreaded applications without the overhead of managing the involved threads?

Kumar: As a matter of fact yes and that's what we use the ThreadPool class for.

Kumar: The thread pool class is an internal .NET runtime's implementation of the threadpool where no more than 25 threads per proc are maintained and a min. of 2 are always there per proc.

Kumar: This thread pool is dynamically grown/shrunk using a GateThread which monitors the request level of the application. When the CPU utilization goes over 95% no more threads are inducted into the threadpool, irrespective of the pending requests and when it goes below 20%, the runtime starts to shrink it..

Kumar: http://www.wintoolzone.com/articles/dotnet_inside_threadpooling.aspx

Kumar: This is the dissection of the threadpool, as implemented by Rotor the closest way to understand .NET. You can see how the two *Queue* methods differ - and what's "unsafe" about one of them

Kumar: The best part of Threadpools is that CLR makes it available to you, irrespective of the OS. Even though in Win2K+, the threadpool is internally implemented by the OS, threads are managed by the CLR. You simply queue requests to it - so, no headache of managing the thread lifetime.

Kumar: So, that's a brief intro to threads/threadpools/AppDomains..

Kumar: Your queries are welcome

DeepakG[MS]: (Anand): Which one you will recommend? A multithreaded app developed using java or that of C# - which one is safe?

Kumar: Hi Anand... let me approach this like this..

Kumar: if you are asking from the context of an equally skilled developer writing the same kind of code for both the JVM and the CLR and the runtimes are using the same APIs to get their work done then my answer would be they would be, more or less at par...

Kumar: On the other hand... if any of the runtimes are using underlying wrapper calls to get their work done while the other doesn't (and CLR doesn't) - then definitely the latter would be better in terms of managing and executing threads is concerned.

DeepakG[MS]: (ab): How does CLR ensure that multithreaded applications give the same performance on all windows operating systems?

Kumar: It will not.. and you know why ?

Kumar: That's because its dependent on the underlying OS!

Kumar: Here's a scenario..

Kumar: a multithreaded app, which is having a high degree of parallelism (ideal situation) - If you run this application on a Win9X architecture OS, say on a dual processor machine and then run the same application on a WinNT architecture OS on the same dual processor machine - the execution on NT will give better performance, other things being equal.

Kumar: This is so since Win9X architecture isn't aware of multi-processors and will never take advantage of the same.

Kumar: On the other hand, WinNT architecture will take advantage of the same and give you better performance - especially since WinNT also has a fairly well designed kernel, that's optimized for multi-proc environments with multiple threads.

Kumar: Thus, it finally boils down to the OS architecture and not the CLR.. since CLR implementation is the same across different OSes. Hope that clears ur doubts

DeepakG[MS]: (ab): What purpose does appdomain really serve in .Net Environment?

Kumar: Good question - it has to do with the ease and performance issues involved in executing code. Understand that in Win32, all code executed within individual processes. So, Word and Excel will be two different processes. Now, the OS CPU Scheduler will allocate the CPU, depending upon the priority of the process, to the process's threads. The context switch involved, also, was significant. Since the PageTables, Page Directory etc.. needed to be updated for each context switch across a process boundary.

Kumar: AppDomains, remove the excess overhead involved in context switch across process Boundary. So, if we have Word.NET and Excel.NET they would be in two different AppDomains but in the same win32 process.

Kumar: Thus, the context switch is minimal as the threads belong to the same process which is running both Word.NET and Excel.NET, hence, better performance..

Kumar: Also, AppDomains maintain the same meaning of each app kicking dust in its

Kumar: own sandbox, without affecting the other applications so, life goes on great then

DeepakG[MS]: (sowmya): Is multi-threading using SDE the same for devices that support ce.net?

Kumar: Another good one... well.. more or less, it is the same. Its only the CLR that is tweaked to work for devices, or desktop or the servers. The concept of implementing and managing threads remains the same. So, while the workstation version will limit not more than 25 threads/processor, this value may be less for CE.NET

DeepakG[MS]: Hi Kumar, we don't have any more questions from the audience. How about sharing some tips and tricks on working with threads...

Kumar: sure...

Kumar: 1) Don't overload your application with threads if you think there will be scenarios, where you may need to service 100's or thousands of requests use the threadpool. The runtime is good at doing this, so let it manage it for you.

Kumar: 2) Be careful when choosing to run your application in its own AppDomain in a *different* Win32 process. It will get affected by the context switch overheads..

Kumar: 3) Remember, threads don't mean better application execution unless your code/design warrants it, your application is better off single threaded..

Kumar: 4) CLR will give you threads and threadpools in the most uniform manner across OS boundaries.

DeepakG[MS]: (ab): For an OS capable of supporting multiple processors even if context switch is eliminated for the Word.NET and Excel.NET example above, Wouldn't talking to different processor nullify the gain by avoiding context switch?

Kumar: That's highly insignificant compared to the time involved in the context switch. To give you an idea if the context switch takes about 10 milliseconds the overhead of managing the threads *from the same process* across multiple processors would be something to the tune of around a nanosec or so - 10 ^ -9. That's a very low value, so, the gain is evident. All the same, the NT OS kernel, when running on such a machine automatically does this... even for traditional multithreaded applications unless you have thread affinity setup.

Kumar: One quick tip before we are done with the chat though threads service multiple AppDomains within the same Win32 process, you cannot make them talk to each other across AppDomain boundaries. If you wish to do that... use other LPC mechanisms like sockets, remoting, pipes etc.

Moderator_MSDNIndia : With this we come to the end of today's session. Thanks Kumar for taking time out for this chat.