Summary

SQL Server 2005 can run in a mode in which it leverages the notion of fibers to improve scalability when running on machines with multiple processors. When running in fiber mode, SQL Server implements a custom scheduler that assigns fibers to physical threads using an algorithm designed to utilize each thread fully to achieve maximum overall throughput. The integration with SQL Server 2005 marks the first time the CLR is required to run in an environment in which tasks are cooperatively scheduled. Until this time, the CLR has been used only in environments in which threads were preemptively scheduled directly by the operating system.

To integrate the CLR with SQL Server 2005 so that scalability isn't hindered, all schedulingrelated activities must be managed directly by SQL Server. The CLR hosting API provides an abstraction called the task manager that hosts can use to supply the CLR with the basic primitives it needs to create and manage how tasks behave in the process. By using the primitives supplied by the host instead of going directly to the operating system, the CLR makes the host (SQL Server 2005, in this case) aware of all threading-related activities that occur in the process such that the execution of managed tasks can be integrated with the host's custom scheduler.

In addition to the primitives needed to control the execution of managed code, the CLR hosting API offers two more abstractions that are needed to integrate the CLR seamlessly with custom schedulers. The first of these abstractions is the synchronization manager. SQL Server 2005 uses a synchronization manager to supply the CLR with synchronization primitives such as events, monitors, and semaphores. Redirecting the requests for such primitives through the host is required for the host to optimize its custom scheduler based on whether a given task is blocked waiting for a synchronization primitive to become available. The final threading-related manager provided by the CLR hosting API is the thread pool manager. Hosts can use the thread pool manager to replace the CLR's custom implementation of the thread pool. The need to cause the CLR to use the host's thread pool also comes from the fact that SQL Server 2005 must be aware of all threads that are currently executing in the process.

The threading, synchronization, and thread pool managers consist of several interfaces with numerous complex methods. Making use of these managers in your own application requires extensive design and testing. This chapter provides an introduction to what is possible. If your scenario requires you to integrate the CLR with a custom scheduler or thread pool, you'll likely find the CoopFiber sample in the .NET Framework SDK an invaluable resource.