计算机线程-外文翻译-外文文献-英文文献.doc

译 文
Chapter 25 Thread Basics
Why Does Windows Support Threads? ...………………………………………….…..…691
Thread Overhead…..…………………………………………………………………….…... 692
Stop the Madness…………..………………………………………………………….……...696
CPU Trends……………………………………………………………………….…..….……699
NUMA Architecture Machines…..……………………………….………………….……..700
CLR Threads and Windows Threads………………………………..……………….…….703
Using a Dedicated Thread to Perform an Asynchronous
Compute-Bound Operation…………………………………………………………….……704
Reasons to Use Threads……..……………………………………………...…………….….706
Thread Scheduling and Priorities……………….……………………..……………….…...708
Foreground Threads versus Background Threads………………………………………..713
What Now?....... .........................................................................................................................715
In this chapter, I introduce the basic concepts concerning threads, and I offer a way for developers to conceptualize about them and their use. I’ll explain why Microsoft Windows introduced the concept of threads, CPU trends, the relationship between common language runtime (CLR) threads and Windows threads, the overhead associated with using threads ,how Windows schedules threads, the Microsoft .NET Framework classes that expose thread properties, and much more.
The chapters in Part V of this book, “Threading,” explain how Windows and the CLR work together to provide a threading architecture. It is my hope that after reading these chapters,you will take away a foundation of knowledge that will allow you to effectively use threads to design and build responsive, reliable, and scalable applications and components.
Why Does Windows Support Threads?
Back in the early days of computers, operating systems didn’t offer the concept of a thread.In effect, there was just one thread of execution that ran throughout the entire system, which included both operating system code and application code. The problem with having only one thread of execution was that a long-running task would prevent other tasks from executing.
For example, in the days of 16-bit Windows, it was very common for an application that was printing a document to stall the entire machine, causing the OS and all other applications to stop responding.
And, sometimes applications would have a bug in them, resulting in an infinite loop that also stopped the entire machine from operating.At this point, the end user would have no choice but to reboot the computer by pressing the reset button or power switch. Of course, end users hated doing this (they still do, in fact) because all running applications terminated; more importantly, any data that these applications were processing was thrown out of memory and lost. Microsoft knew that 16-bit Windows would not be a good enough operating system to keep Microsoft relevant
as the computer industry progressed, so they set out to build a new OS to address the needs of corporations and individuals. This new OS had to be robust, reliable, scalable, and secure, and it had to improve the many deficiencies of 16-bit Windows. This OS kernel originally shipped in Microsoft Windows NT. Over the years, this kernel has had many tweaks and features added to it. The latest version of this kernel ships in the latest versions of the Microsoft client and server Windows operating systems.
When Microsoft was designing this OS kernel, they decided to run each instance of an application in what is called a process. A process is just a collection of resources that is used by a single instance of an application. Each process is given a virtual address space, ensuring that the code and data used by one process is not accessible to another process. This makes application instances robust because one process cannot corrupt code or data being used by another. In addition, the OS’s kernel code and data are not accessible to processes; therefore,it’s not possible for application code to corrupt operating system code or data. So now,application code cannot corrupt other applications or the OS itself, and the whole computing experience is much better for end users. In addition, the system is more secure because application code cannot access user names, passwords, credit card information, or other sensitive information that is in use by another application or the operating system itself.
This is all well and good, but what about the CPU itself? What if an application enters an infinite loop? Well, if there is only one CPU in the machine, then it executes the infinite loop and cannot execute anything else, so while the data cannot be corrupted and is more secure,the system could still stop responding to the end user. Microsoft needed to fix this problem,too, and threads were the answer. A thread is a Windows concept whose job is to virtualize the CPU. Windows gives each process its very own thread (which functions similar to a CPU),and if application code enters an infinite loop, the process associated with that code freezesup, but other processes (which have their own threads) are not frozen; they keep running!
Thread Overhead
Threads are awesome because they enable Windows to be responsive even when applicationsare executing long-running tasks. Also, threads allow the user to use one application(like Task Manager) to forcibly kill an application that appears frozen because it is executing a long-running task. But as with every virtualization mechanism, threads have space (memory consumption) and time (runtime execution performance) overhead associated with them.Let’s explore this overhead in more detail now. Every thread has one of each of the following:
l Thread kernel object The OS allocates and initializes one of these data structures for each thread created in the system. The data structure contains a bunch of properties(discussed later in this chapter) that describe the thread. This data structure also contains what is called the thread’s context. The context is a block of memory that contains a set of the CPU’s registers. When Windows is running on a machine with an x86 CPU, the thread’s context uses about 700 bytes of memory. For x64 and IA64 CPUs, the context is about 1,240 and 2,500 bytes of memory, respectively.
l Thread environment block (TEB) The TEB is a block of memory allocated and initialized in user mode (address space that application code can quickly access). The TEB consumes 1 page of memory (4 KB on x86 and x64 CPUs, 8 KB on an IA64 CPU).The TEB contains the head of the thread’s exception-handling chain. Each try block that the thread enters inserts a node in the head of this chain; the node is removed from the chain when the thread exists in the try block. In addition, the TEB contains the thread’s thread-local storage data as well as some data structures for use by Graphics Device Interface (GDI) and OpenGL graphics.
l User-mode stack The user-mode stack is used for local variables and arguments passed to methods. It also contains the address indicating what the thread should execute next when the current method returns. By default, Windows allocates 1 MB of memory for each thread’s user-mode stack.
l Kernel-mode stack The kernel-mode stack is also used when application code passes arguments to a kernel-mode function in the operating system. For security reasons,Windows copies any arguments passed from user-mode code to the kernel from the thread’s user-mode stack to the thread’s kernel-mode stack. Once copied, the kernel can verify the arguments’ values, and since the application code can’t access the kernelmode stack, the application can’t modify the arguments’ values after they have been validated and the OS kernel code begins to operate on them. In addition, the kernel calls methods within itself and uses the kernel-mode stack to pass its own arguments,to store a function’s local variables, and to store return addresses. The kernel-mode stack is 12 KB when running on a 32-bit Windows system and 24 KB when running on a 64-bit Windows system.
l DLL thread-attach and thread-detach notifications Windows has a policy that whenever a thread is created in a process, all DLLs loaded in that process have their DllMain method called, passing a DLL_THREAD_ATTACH flag. Similarly, whenever a thread dies, all DLLs in the process have their DllMain method called, passing it a DLL_THREAD_DETACH flag. Some DLLs need these notifications to perform some special initialization or cleanup for each thread created/destroyed in the process. For example,the C-Runtime library DLL allocates some thread-local storage state that is required should the thread use functions contained within the C-Runtime library.
In the early days of Windows, many processes had maybe 5 or 6 DLLs loaded into them,but today, some processes have several hundred DLLs loaded into them. Right now, on mymachine, Microsoft Office Outlook has about 250 DLLs loaded into its process address space!This means that whenever a new thread is created in Office Outlook, 250 DLL functions must get called before the thread is allowed to do what it was created to do. And these 250 functions must be called again whenever a thread in Outlook dies. Wow—this can seriously affect the performance of creating and destroying threads within a process.
So now, you see all the space and time overhead that is associated with creating a thread, letting it sit around in the system, and destroying it. But the situation gets even worse—nowwe’re going to start talking about context switching. A computer with only one CPU in it can do only one thing at a time. Therefore, Windows has to share the actual CPU hardware among all the threads (logical CPUs) that are sitting around in the system.
At any given moment in time, Windows assigns one thread to a CPU. That thread is allowed to run for a time-slice (sometimes referred to as a quantum). When the time-slice expires,Windows context switches to another thread. Every context switch requires that Windows performs the following actions:
1. Save the values in the CPU’s registers to the currently running thread’s context structure inside the thread’s kernel object.
2. Select one thread from the set of existing threads to schedule next. If this thread is owned by another process, then Windows must also switch the virtual address spaceseen by the CPU before it starts executing any code or touching any data.
3. Load the values in the selected thread’s context structure into the CPU’s registers.After the context switch is complete, the CPU executes the selected thread until its time-slice expires, and then another context switch happens again. Windows performs context switches about every 30 ms. Context switches are pure overhead; that is, there is no memory or performance benefit that comes from context switches. Windows performs context switching to provide end users with a robust and responsive operating system.
Now, if an application’s thread enters into an infinite loop, Windows will periodically preempt that thread, assign a different thread to an actual CPU, and let this other thread run for a while. This other thread could be Task Manager’s thread and now, the end user can use Task Manager to kill the process containing the thread that is in an infinite loop. When doing this, the process dies and all the data it was working on is destroyed, too, but all other processes in the system continue to run just fine without losing their data. Of course, the user doesn’t have to reset the machine and reboot, so context switches are required to provide end users with a much better overall experience at the cost of performance.
In fact, the performance hit is much worse than you might think. Yes, a performance hit occurs when Windows context switches to another thread. But the CPU was executing another thread, and the previously running thread’s code and data reside in the CPU’s caches so that the CPU doesn’t have to access RAM memory as much, which has significant latency associated with it. When Windows context switches to a new thread, this new thread is most likely executing different code and accessing different data that is not in the CPU’s cache. The CPU must access RAM memory to populate its cache so it can get back to a good execution speed. But then, about 30 ms later, another context switch occurs.
The time required to perform a context switch varies with different CPU architectures and speed. And the time required to build up a CPU’s cache depends on what applications are running in the system, the size of the CPU’s caches, and various other factors. So it is impossible for me to give you an absolute figure or even an estimate as to what time overhead is incurred for each context switch. Suffice it to say that you want to avoid using context switches as much as possible if you are interested in building high-performing applications and components.
Important At the end of a time-slice, if Windows decides to schedule the same thread again(rather than switching to another thread), then Windows does not perform a context switch.Instead, the thread is allowed to just continue running. This improves performance significantly, and avoiding context switches is something you want to achieve as often as possible when you design your code.
Important A thread can voluntarily end its time-slice early, which happens quite frequently because threads typically wait for I/O operations (keyboard, mouse, file, network, etc.) to complete. For example, Notepad’s thread usually sits idle with nothing to do; this thread is waiting for input. If the user presses the J key on the keyboard, Windows wakes Notepad’s thread to have it process the J keystroke. It may take Notepad’s thread just 5 ms to process the key, and then it calls a Win32 function that tells Windows that it is ready to process the next input event. If there are no more input events, then Windows puts Notepad’s thread into a wait state (relinquishing the remainder of its time-slice) so that the thread is not scheduled on any CPU until the next input stimulus occurs. This improves overall system performance since threads
that are waiting for I/O operations to complete are not scheduled on a CPU and do not waste CPU time; other threads can be scheduled on the CPU instead.
In addition, when performing a garbage collection, the CLR must suspend all the threads,walk their stacks to find the roots to mark objects in the heap, walk their stacks again(updating roots to objects that moved during compaction), and then resume all the threads.So avoiding threads will greatly improve the performance of the garbage collector, too. And whenever you are using a debugger, Windows suspends all threads in the application being debugged every time a breakpoint is hit and resumes all the threads when you single-step or run the application. So the more threads you have, the slower your debugging experience will be.
From this discussion, you should conclude that you must avoid using threads as much as poss