Threading in Delphi for .NET - Threading
(Page 2 of 15 )
Threading overcomes many disadvantages of using processes to perform background processing. Threading allows for multiple independent paths within a process to be executed simultaneously. Each path of execution is referred to as a thread.
Note - Technically, these independent paths can only run simultaneously on a machine with multiple processors. Single-processor machines switch between these independent paths rapidly, giving the illusion of simultaneous execution.
Most processes only have a single path of execution—a single threaded process. Processes containing multiple paths are called multithreaded. Figure 14.2 illustrates single-threaded and multithreaded processes.
Figure 14.2 - Single and multithreaded processes.
Each thread in a process has its own instruction pointer and CPU registers. All threads share the same virtual address space that is owned by the containing process. However, each thread receives its own stack space.
Because all threads within a process share the same address space, communication between threads is trivial. While easily accomplished, sharing address space requires diligent design. This topic is discussed later in this chapter.
The operating system gives each thread a time slice of the processor. Using a complex algorithm, the operating system looks at the thread's priority and whether it is waiting for something to occur. After a thread has either blocked or used up its time slice, the scheduler looks for another thread to execute.
Lightweight is a term associated with a thread because they require fewer resources than processes. Threads start and stop much more quickly than processes.
Threading .NET Style
As expected, the .NET Framework also has the concept of threading that is nicely wrapped in an object-oriented and platform-neutral fashion. By encapsulating and abstracting threading, the framework exposes a logical thread. These logical threads are managed by the framework and provide additional benefits not found in a physical Win32 thread. Using .NET Threads should make the code much more portable to other CLI platforms such as WinCE, Win64, and Mono. At the time of this writing, a logical thread maps to a physical thread, but this might change in future versions of .NET.
A logical thread is capable of doing things that a native thread cannot. For example, there is no simple method for a native thread to raise an exception in another thread. Logical threads, however, can raise an exception in another thread by calling the Thread.Abort() method. Exceptions are discussed in the "Threading Exceptions" section.
Logical .NET threads are scheduled by the CLR and run in the context of an AppDomain.
AppDomain
Similar to a process, an AppDomain provides a secure sandbox for .NET executables and assemblies. Just as multiple processes are protected, multiple .NET assemblies are protected if they reside in separate AppDomains. One important distinction is that AppDomains do not have to necessarily reside in separate processes. Multiple AppDomains can, and often do, occupy the same Win32 process.
When a .NET application is loaded, the CLR creates a process. In turn, this process creates the first AppDomain, which is called the default AppDomain. The default AppDomain cannot be unloaded and is destroyed when the process finishes. Additional AppDomains can be created dynamically at runtime. The relationship between processes and AppDomains is illustrated in Figure 14.3.
Figure 14.3 - The Process/AppDomain relationship.
Like multiple processes, if an assembly needs to communicate with another assembly located in a different AppDomain, some IPC mechanism is required such as .NET Remoting. Unlike multiple processes, the major distinction between AppDomains and Win32 processes is that AppDomains cannot currently share a common memory segment, whereas Win32 applications can.
AppDomains provide the capability to unloaded assemblies, as long as they are not located in the default AppDomain. All assemblies contained in an AppDomain are unloaded when the AppDomain is unloaded.
Configuration and security policies can be applied to an AppDomain to form either a more restrictive or relaxed environment.
 This chapter is from Delphi for .NET Developer's Guide, by Xavier Pacheco (Sams, 2004, ISBN: 0-672-32443-1). Check it out at your favorite bookstore today.
Buy this book now. |
Next: The System.Threading Namespace >>
More .NET Articles
More By Xavier Pacheco
