MSDN Magazine - December 2008 - (Page 15)

ERIka FuEnTEs anD ERIC EILEbREChT CLR InsIde Out Thread Management In The CLR The ongoing technological evolution from singlecore to manycore architectures is bringing great benefits. Consider, for instance, a threaded environment where the efficient use of multiple threads can promote better performance through the use of multiple cores and parallelism, for example, an ASP.NET application using multiple threads to make many independent queries to a database. Using multiple cores does bring about new problems, however. You’ll likely see an increase in the complexity of programming and synchronization models, you’ll need to control concurrency, and performance tuning and optimization will be more difficult. Additionally, many of the new factors that affect the performance and behavior of concurrent applications are not well understood. Thus, tuning for performance has become challenging, especially when the targeted optimizations are not application-specific but rather general purpose. Threading in the CLR is an example of a concurrent environment where many factors (such as those introduced by multiplecore architectures) can influence the behavior and performance of concurrency. Lock and cache contention and excessive context switching are just a few. Ongoing work on the CLR ThreadPool aims to make it easier for developers to exploit concurrency and parallelism for higher concurrency levels and better performance by integrating the Parallel Frameworks into the runtime and internally dealing with some of the most common problems. In this column, we will describe some of the common issues developers encounter and the important factors to be considered when tuning multithreaded managed code, particularly in multiprocessor hardware. We also describe how future changes in the ThreadPool should deal with some of these issues and help alleviate the programmers’ work. Furthermore, we will discuss some important aspects of concurrency control, which can help you to understand the behavior of apps in highly multithreaded environments. We will assume that you are familiar with the basic concepts of concurrency, synchronization, and threading in the CLR. The discrepancy between task fairness and performance is critical in a concurrent environment. threaded applications scale poorly for use with multiple cores. Even worse, it is not straightforward to adapt the single-threaded model to multiple cores. Many of the causes are predictable—synchronization issues such as lock and resource contention, race conditions, and starvation. Other causes are not yet well understood. For example, how do you determine the best concurrency level (number of threads) at any given time for a particular type (and size) of workload? Consider the threading system in the CLR, which was designed to operate on a single-core machine: the tasks (WorkItems) are queued in a single list protected by one lock. Each thread then sequentially consumes the items from the queue. When this is migrated to a multicore architecture, its performance degrades when there’s a lot of contention on the lock for higher concurrency levels. Interestingly, in his October 2008 Windows With C++ column, “Exploring High-Performance Algorithms” (msdn.microsoft.com/magazine/cc850829), Kenny Kerr said that “a well-designed algorithm on a single processor can often outperform an inefficient implementation on multiple processors,” implying that simply adding more processors does not always improve performance. From here on, we’ll loosely refer to the existing threading system as the ThreadPool and to the concept of WorkItem as an item in the tasks queue (a QueueUserWorkItem, for example). In single-core machines, managing concurrency could be handled with the careful scheduling of tasks by dividing the processor’s time among the threads. Now that there’s more than one core, you also must consider how to fairly distribute work among the cores, consider the underlying memory hierarchy for correctness and performance, and decide how to control and exploit higher concurrency levels. Fairness vs. Performance The discrepancy between task fairness and performance is critical in a concurrent environment: it’s nearly impossible to get fair task scheduling and overall high performance at the same time. ConThis column is based on prerelease versions of the CLR Threading System and the Task Parallel Libraries. All information is subject to change. Send your questions and comments to clrinout@microsoft.com. December 2008 15 Common Issues in Concurrency Most software was designed for single-threaded execution. In part, this is because the programming model of single-threaded execution reduces complexity and is easier to code. Existing single- http://msdn.microsoft.com/en-us/magazine/cc850829 http://msdn.microsoft.com/en-us/magazine/cc850829

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.