Process, AppDomains and Threads

Reviewing Processes and Threads Under Traditional Win32
The concept of processes and threads has existed within Windows-based operating systems well before the release of the .NET platform. Simply put, process is the term used to describe the set of resources (such as external code libraries and the primary thread) as well as the necessary memory allocations used by a running application. For each *.exe loaded into memory, the operating system creates a separate and isolated memory partition (aka process) for use during its lifetime. Using this approach to application isolation, the result is a much more robust and stable runtime environment, given that the failure of one process does not effect the functioning of another.
..........

Understanding the System.AppDomain Type

unlike a traditional (non-.NET) Win32 *.exe application, .NET assemblies are hosted in a logical partition within a process termed an application domain (aka AppDomain) and many application domains can be hosted inside a single OS process. This additional subdivision of a traditional Win32 process offers several benefits, some of which are:

• AppDomains are a key aspect of the OS-neutral nature of the .NET platform, given that this logical division abstracts away the differences in how an underlying operating system represents a loaded executable.
• AppDomains are far less expensive in terms of processing power and memory than a full blown process (for example, 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.

......

Context

As you have just seen, AppDomains are logical partitions within a process used to host .NET assemblies. A given application domain may be further subdivided into numerous context boundaries. In a nutshell, a .NET context provides a way for a single AppDomain to partition .NET objects that have similar execution requirements. Using context, the CLR is able to ensure that objects that have special runtime requirements are handled appropriately and in a consistent manner by intercepting method invocations into and out of a given context. This layer of interception allows CLR to adjust the current method invocation to conform to the contextual settings of a given type.

......

The Process/AppDomain/Context/Thread Relationship
As mentioned at the opening of this chapter, a thread is a path of execution within a loaded application. While many .NET applications can live happy and productive single-threaded lives, the primary thread may spawn secondary threads of execution to perform additional units of work. In just a moment, you will be introduced to the System.Threading namespace, which defines numerous types used to create multithreaded .NET applications. First however, we need to check out exactly "where" a thread lives within a .NET process.

The first thing you must understand is that under the .NET platform, there is not a direct one-to-one correlation between application domains and threads. In fact, a given AppDomain can have numerous threads executing within it at any given time. Furthermore, a particular thread is not confined to a single application domain during its lifetime. Threads are free to cross application domain boundaries as the thread scheduler and the CLR see fit.

Although active threads can be moved between application boundaries, a given thread can only execute within a single application domain at any point in time (in other words, it is impossible for a single thread to be doing work in more than one AppDomain).
.......
.......
.......
Summary
The point of this chapter was to expose the internal composition of a .NET executable image. As you have seen, the long-standing notion of a Win32 process has been altered under the hood to accommodate the needs of the CLR. A single process (which can be programmatically manipulated via the System.Diagnostics.Process type) is now composed on multiple application domains, which represent isolated and independent boundaries within a process. As you recall, a single process can host multiple application domains, each of which is capable of hosting and executing any number of related assemblies. Furthermore, a single application domain can contain any number of contextual boundaries. Using this additional level of type isolation, the CLR can ensure that special-need objects are handled correctly.

The remainder of this chapter examined the role of the System.Threading namespace. As you have seen, when an application creates additional threads of execution, the result is that the program in question is able to carry out numerous tasks at (what appears to be) the same time. Finally, the chapter examined various manners in which you can mark thread-sensitive blocks of code to ensure that shared resources do not become unusable units of bogus data.

Very good!!

using System;
class Test {
static void Main() {
AppDomain d = AppDomain.CreateDomain("NewDomain");
Console.WriteLine("Host domain:  "  + AppDomain.CurrentDomain.FriendlyName);
Console.WriteLine("Child domain:  "   + d.FriendlyName);
  }
}

output

c:\Windows\MICROS~1.NET\FRAMEW~1\V20~1.507>ADomain.exe
Host domain:  ADomain.exe
Child domain:  NewDomain

More detailed

  private void button1_Click(object sender, EventArgs e)
        {
            //AppDomain d = AppDomain.CreateDomain("NewDomain");
           // AppDomain.MonitoringIsEnabled = true;
            //int mt = AppDomain.CurrentDomain. MonitoringTotalProcessorTime.Milliseconds;
            //string ms = AppDomain.CurrentDomain.MonitoringTotalAllocatedMemorySize.ToString();
            //string mas = AppDomain.CurrentDomain.MonitoringSurvivedMemorySize.ToString();
            textBox1.Text = AppDomain.CurrentDomain.FriendlyName.ToString();
            List a=AppDomain.CurrentDomain.GetAssemblies().ToList();
           
            Context ctx = Thread.CurrentContext;

            textBox2.Text = a.Count.ToString() + ctx.ContextID.ToString() + Thread.GetDomain();
           
        }