Building Multithreaded Applications—The Process/AppDomain/Context/Thread Relationship

CSharp-Online.NET:Articles

C# Articles

Building Multithreaded Apps P/A/C/T Relationships § Thread Synchronization .NET Delegate Asynchronous Nature § Invoke Asynchronously § System.Threading System.Threading.Thread § Secondary Threads § Concurrency Issue § Timer Callbacks CLR ThreadPool Summary

© 2005 Andrew Troelsen

The Process/AppDomain/Context/Thread Relationship

In the previous chapter, a thread was defined as a path of execution within an executable application. While many .NET applications can live happy and productive single-threaded lives, an assembly’s primary thread (spawned by the CLR when Main() executes) may create secondary threads of execution to perform additional units of work. By implementing additional threads, you can build more responsive (but not necessarily faster executing) applications.

The System.Threading namespace contains various types that allow you to create multithreaded applications. The Thread class is perhaps the core type, as it represents a given thread. If you wish to programmatically obtain a reference to the thread currently executing a given member, simply call the static Thread.CurrentThread property:

private static void ExtractExecutingThread()
{
     // Get the thread currently 
     // executing this method.
     Thread currThread = Thread.CurrentThread;
}

Under the .NET platform, there is not a direct one-to-one correspondence 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 Win32 thread scheduler and CLR see fit.

Although active threads can be moved between AppDomain boundaries, a given thread can execute within only 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). When you wish to programmatically gain access to the AppDomain that is hosting the current thread, call the static Thread.GetDomain() method:

private static void ExtractAppDomainHostingThread()
{
     // Obtain the AppDomain hosting the current thread.
     AppDomain ad = Thread.GetDomain();
}

A single thread may also be moved into a particular context at any given time, and it may be relocated within a new context at the whim of the CLR. When you wish to obtain the current context a thread happens to be executing in, make use of the static Thread.CurrentContext property:

private static void ExtractCurrentThreadContext()
{
     // Obtain the Context under which the
     // current thread is operating.
     Context ctx = Thread.CurrentContext;
}

Again, the CLR is the entity that is in charge of moving threads into (and out of) application domains and contexts. As a .NET developer, you can usually remain blissfully unaware where a given thread ends up (or exactly when it is placed into its new boundary). Nevertheless, you should be aware of the various ways of obtaining the underlying primitives.