Patterns : a look

A pattern is an especially clever and insightful way of solving a particular class of problems. It represents a complete idea within a program, and thus it can sometimes appear at the analysis phase or high-level design phase. It can exist at many levels from very low-level specific solutions to broadly generalized system issues. A patterns cover various ranges of scale and abstraction and are grouped into three categories:
    1. Architectural Pattern
        An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.
    2. Design Patterns
        A Design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communication components that solves a general design problem within a particular context.
    3. Idioms
        An idioms is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

Some useful definitions of Design Patterns have emerged as the literature in this field has expanded.

• “Design patterns are recurring solutions to design problems you see over and over.” (The Smalltalk Companion)
• “Design patterns constitute a set of rules describing how to accomplish certain tasks in the realm of software development.” (Pree 1994)
• “Design patterns focus more on reuse of recurring architectural design themes, while frameworks focus on detailed design and implementation.” (Coplien and Schmidt 1995)
• “A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it.” (Buschmann et al., 1996)
• “Patterns identify and specify abstractions that are above the level of single classes and instances, or of components.” (Gamma et al., 1993)

SQLOS : A User-mode Operating System for SQL Server

    The SQLOS is core to SQL Server's architecture, and first implemented in SQL Server 2005. It is a framework used by components in SQL Server for scheduling, I/O, and memory management. Because of the highly specialized requirements of SQL Server, it implements its own thread and memory management system. It is used for low-level operations such as scheduling, I/O completion, memory management, buffer pool management, resource management, synchronization primitives and deadlock detection. In summary, the SQLOS is a thin user-mode layer that sits between SQL Server and Windows.
    SQLOS also recognizes and accommodates NUMA (non-uniform memory access) architectures, to handle the systems which scale above 32 cores. In database, scheduled query run must be complete before starting the next one. SQLOS manages that with its schedulers: each logical CPU (one care in multi-core chip) has a non-preemptive scheduler in SQLOS that assigns one thread at a time to the CPU. SQLOS schedulers are hyper-threading aware, and can move a task from a hyper-threaded CPU to a "real" CPU that becomes idle.

The benefits of SQLOS include 

• performance (primary goal)
• enhanced scheduling and processor locality 
• a dedicated administrative connection
• support for hot adding of memory and CPU resources
• a hosting interface for services such as CLR and SQL Server 2008 Reporting Services

    Reporting Services are runs under SQLOS rather than IIS, to handle large report request in a reasonable way. IIS is not designed to service long-running requests like database reports. Only Microsoft SQL Server can benefit from SQLOS. It is a tightly coupled, private layer of SQL Server. Even an extended stored procedure (a function in a DLL that SQL Sever launches) get called, it is thrown on the mercy of the Windows scheduler rather than receiving the benefit of SQLOS's non-preemptive scheduler.

    SQLOS is not a way to port the SQL Server architecture to other platforms like Linux or Mac OS so it's not an OS abstraction layer. It doesn't wrap all the OS APIs like other frameworks such as .NET, which is why it's referred to as a "thin" user-mode layer.