Servers with multiple processor cores, NewSQL, cloud computing, and advanced analytics have put a spotlight on extensible database architecture. It has long been possible to use a plugin to add functionality to a database, such as a new type, just as we can use add-ins to extend a Web browser. But today we see plugins gaining traction for a variety of purposes. If you are building a new database management system (DBMS) or simply want to write better database applications, you should be aware of the extensible architecture of operating systems and database managers.
- Blue Coat Research Report: The Visibility Void
- Coding to standards and quality: supply-chain application development
- Agile Desktop Infrastructures: You CAN Have It All
- Client Windows Migration: Expert Tips for Application Readiness
To undertake a study of kernels, microkernels, and database architecture, a good departure point is found in some features of modern processors.
Processor Operating Modes
Processors have long supported multiple operating modes to segregate system services and application code at execution time. The purpose of these designs was to afford a level of protection for the routines that comprised the system software. The idea is that you don't want faulty application code to overwrite a part of memory that's used by the operating system (OS); overwriting memory or data can cause a crash.
The venerable IBM System 360 mainframe of the 1960s was a processor that offered a separation between System State and User State. The former was intended for code that executed to provide OS services when a program executed a supervisor call (SVC). The latter was how applications normally operated.
IBM OS/360 was designed during an era of expensive main memory, when machines with 512K of memory were the top of the line. To keep the operating system to a manageable size, IBM developed an extensible OS architecture. It supported the execution of Transient SVCs: small (2K) special-purpose modules that executed in a transient program area of memory.
The popular PDP 11 series minicomputer offered multiple processor modes (Supervisor, User, and Kernel mode); it also offered separate memory spaces for instructions and data. The Intel Xeon processor (in fact, all Intel processors since the 386) also has three processor modes. A program can operate in Real Mode, Protected Mode, or SMM Mode. These processor architectures enable us to write programs that change from one mode to another for critical operations, such as invoking an interrupt service routine that executes in kernel mode. A mode transition goes hand-in-hand with a context switch that preserves and restores the state of the CPU. Table 1 shows a breakdown of processor modes.
|Computer||Processor Modes (Operating States)|
|IBM System 360||System, User|
|Digital PDP 11||Supervisor, User, Kernel|
|Intel Xeon||Real, Protected, SMM|
Memory-managed computers and multiple processor modes added the term "context switch" to the programming lexicon. In a protected memory environment, "context" refers to a virtual address space containing executable code. Various activities, such as invoking a kernel mode function or preempting a task, will initiate a context switch for the purpose of storing state information for the old executing task and retrieving state information for the new code.
The context switch has been integral to modern systems and is essential for multitasking operations. With today's processors and operating systems, the term takes on a broader meaning. You can have register, task, thread, or process context switches. Some processors now provide hardware support for context switching by providing a data segment for task state information.