Processes, Threads, AppDomains and Object Contexts

When I was new in .NET, one question always confuses me and that question is: What is the difference between Processes, Threads, Application Domains and Object Context and how they work internally?

I read good articles on these topic one or two weeks back. Today I got time to write so let’s begin…


Process:
Process term used to describe the set of resources and the necessary memory allocations used by a running application. In Windows OS, for each *.exe loaded into memory, the OS create a separate and isolated process.

Using this application isolation approach, OS can manage application more robustly. The result is a much more robust and stable environment, given that the failure of one process does not affect the other process. You can see list of running process using Windows Task Manager in Windows OS.

.NET provides number of classes to interact with processes. The System.Diagnostics namespace defines a number of types that allow you to programmatically interact with processes.

Threads:
Thread is a path of execution within a process.

Every Win32 process has exactly one main “thread” that functions as the entry point for the application and this thread known as Primary Thread.

Processes that contain a single primary thread of execution are intrinsically thread safe, given the fact that there is only one thread that can access the data in the application at a given time. However, a single-threaded process will often appear a bit unresponsive to the user if this single thread is performing a complex operation (such as printing out a lengthy text file, performing a mathematically intensive calculation, or attempting to connect to a remote server located thousands of miles away).

.NET provides facility to spawn additional secondary threads also termed Worker Threads. If worker thread is busy with other operation, the main thread is still responsive to user input, which gives the entire process the potential of delivering greater performance. The System.Threading namespace contains various types that allow you to create multithreaded applications.

Application Domains:
The traditional Win32 application directly hosted within a process, while .NET executables are not hosted directly within a process. Rather, a .NET executable is hosted by a logical partition within a process termed as application domain.

This additional subdivision of process offers sever benefits, some of them are:

• AppDomains are far less expensive in terms of processing power and memory than a fullblown process. Thus, the CLR is able to load and unload application domains much quicker than a formal process.
• AppDomains provide a deeper level of isolation for hosting a loaded application. If one
AppDomain within a process fails, the remaining AppDomains remain functional.

As suggested in previous list, a single process can host any number of AppDomains. Given this fact, be very aware that an application running in one AppDomain is unable to obtain data of any kind (global variables or static fields) within another AppDomain unless they make use of a distributed programming protocol (such as Windows Communication Foundation).

Every process contains at least one application domain which termed as default application domain. This specific application domain is automatically created by the CLR at the time the process launches. After this point, the CLR creates additional application domains on an as-needed basis.

We can also create Application Domain programmatically using System.AppDomain class.

Object Context:
Application domain further subdivided into numerous context boundaries. Using context, the CLR is able to ensure that objects that have special runtime requirements are handled in an appropriate and consistent manner by intercepting method invocations into and out of a given context. For example, if you define a C# class type that requires automatic thread safety (using the [Synchronization] attribute), the CLR will create a “synchronized context” during allocation.

Just as a process defines a default AppDomain, every application domain has a default context. This default context (sometimes referred to as context 0) is used to group together .NET objects that have no specific or unique contextual needs. As you may expect, a vast majority of .NET objects are loaded into context 0. If the CLR determines a newly created object has special needs, a new context boundary is created within the hosting application domain.

Context-agile objects: .NET types that do not demand any special context are termed context-agile objects.

Context-bound objects: .NET types that demand special context allocation are termed context-agile objects.