Lesson 6 - The Input/Output Model

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
On This Page

What You Will Learn
Thinking Ahead
What To Do
Before Going On
Speaking The Language
To Learn More

What You Will Learn

By the end of this lesson, you should be able to do the following:

  • Explain the advantages of the device driver architecture used in Windows NT over the device driver architectures used in MS-DOS and Windows 3.1.

  • Explain what various Windows NT I/O features are and why they're important, including mapped file I/O, disk caching, asynchronous I/O, and dynamic loading and unloading of drivers (not supported by all device drivers in Windows NT version 3.1).

  • Describe the basic components of the Windows NT I/O system and how they relate to each other, including tracing both synchronous and asynchronous I/O requests through the components.

  • Explain the advantages of the layered device driver and file system design in Windows NT.

Using knowledge learned in this module, you'll be able to explain the following:

  • How Windows NT can support multiple file systems on mixed device types.

Thinking Ahead

What To Do

Departing From The Windows for MS-DOS I/O Model

The I/O system used in Windows for MS-DOS is based on, and limited by, capabilities of the underlying MS-DOS operating system. The device drivers at the core of this I/O system are commonly:

  • Written in assembly language--they're not portable: they can only run on Intel 80x86 family processors.

  • Monolithic in design, not layered--similar code for common tasks is repeated in each device driver for a given class of devices. Monolithic design also makes mixing and matching different file systems and device drivers impossible.

  • Not designed for preemptive multitasking use--Windows has to perform many nasty tricks to allow even non-preemptive multitasking with non-multitasking MS-DOS and its non-multitasking device drivers.

  • Incompatible with multiprocessor platforms--MS-DOS is inherently a single-processor OS, so MS-DOS device drivers are utterly incapable of synchronizing access to shared resources in a multiprocessor situation.

For these reasons, it was necessary to compromise device driver compatibility with Windows for MS-DOS and design a new I/O system for Windows NT. You may have to explain these reasons to customers who are upset about this incompatibility.

The MS-DOS I/O system model simply could not be extended to provide many of the advanced features of Windows NT. Windows NT device drivers are:

  • Mostly written in portable high-level language--therefore, these drivers are far more easily portable than MS-DOS or Windows for MS-DOS device drivers. This is crucial since Windows NT runs on a variety of different platforms.

  • Designed for preemptive multitasking on multiprocessor platforms.

  • Designed in layers to allow multiple installable file systems, multiple device drivers, and multiple network providers to all coexist.

Windows NT I/O System Architecture

The architecture of the Windows NT I/O system provides support for many of the operating system's advanced features. The I/O system consists of a set of layered drivers whose actions are coordinated by an NT Executive component called the I/O manager (Figure 1).

A large part of the I/O manager's role is the management of communication between drivers. All drivers supply a standard set of services that the I/O manager can call. This uniform interface allows the I/O manager to communicate with all drivers in the same way, without any knowledge of how the devices they control actually work.

Drivers communicate with each other using data structures called I/O request packets . The drivers do not pass I/O request packets to each other directly. Instead, they pass the packets to the I/O manager, which delivers them to the appropriate destination drivers using the drivers' standard services. The packets passed at the various stages are different--it's a primary job of each layer to construct the appropriate request packets to pass to the next layer.

Layered Drivers

The Windows NT I/O system allows separate drivers to implement each logically distinct layer of I/O processing. For example, drivers in the lowest layer manipulate the computer's physical devices (these are called device drivers ). Other drivers are then layered on top of the device drivers. These higher-level drivers do not know any details about the physical devices. With the I/O manager's help, they simply pass logical I/O requests down to the device drivers, which access the physical devices on their behalf. Windows NT's installable file systems and network redirectors are examples of high-level drivers that work in this way.

Layered drivers have several advantages over monolithic drivers. In particular, they are:

  • Easier To Develop - Common code can be implemented once and shared by many drivers. This makes layered drivers generally smaller and simpler to write than monolithic drivers.

  • Easier To Maintain - Changes in a driver in one layer rarely affect drivers in other layers because each layer represents a different level of I/O abstraction.

  • More Reliable - Since less work is required to write each driver, the chances of introducing coding errors is minimized.

  • More Flexible - A new layered drivers can easily be inserted between two existing drivers to change the I/O system's behavior. This is not possible with monolithic drivers because the entire driver would need to be replaced to change its behavior.

Note that this scheme allows easy replacement of file system drivers and device drivers--it even allows multiple file systems and devices to be active at the same time while being addressed through a common interface.

Tracing A Simple I/O Request Through The System

The simplest way to perform I/O is to synchronize the execution of applications with completion of the I/O operations that they request. When an application performs an I/O operation, the application's execution is blocked. When the I/O operation is complete, the application is allowed to continue execution. This simple I/O is commonly referred to as synchronous I/O .

When an environment subsystem issues a synchronous I/O request on behalf of an application, it calls a Windows NT system I/O service. The I/O manager then gets control and constructs one or more structures called I/O request packets. It then passes these packets to the appropriate file system driver, which calls back into the I/O manager. As part of processing that callback, the I/O manager calls the device driver, which manipulates the hardware directly. The various parts then return status to each other in reverse order until finally status is returned to the environment subsystem and the application.

Tracing A More Efficient I/O Request

One way that applications can optimize their performance is to perform asynchronous I/O . When an application initiates an I/O operation, the I/O system accepts the request but it does not block the application's execution while the I/O operation is being performed. Instead, the application is allowed to continue doing work. Most I/O devices are very slow in comparison to a computer's processor, so an application can do a lot of work while waiting for an I/O operation to complete.

When an environment subsystem issues an asynchronous I/O request, the I/O manager does the same I/O request packet packaging as before. The difference is that the I/O manager returns to the environment subsystem immediately after putting the request in a queue, without waiting for the file system and device to complete their operations.

Meanwhile, a separate thread of the I/O manager executes requests from the queue in the most efficient order (not necessarily the order received).

When each I/O request is finished, the I/O manager notifies the process that requested the I/O.

While asynchronous I/O permits an application to utilize the computer's processor during I/O operations, it also makes it harder for the application to determine when I/O operations have completed. Some applications provide a callback function that is called when the asynchronous I/O operation is completed. Other applications provide an object that the I/O system sets to the signalled state when the I/O operation is complete.

It is interesting to note that the I/O system does not guarantee the order in which asynchronous I/O requests will be processed. It is possible that asynchronous I/O requests could be completed in a different order than they were initiated.

Designing Drivers to Support Multiprocessing

Windows NT's ability to run on machines with multiple processors has a direct impact on the design of its device drivers. Its drivers must be designed to run on any processor. In fact, a driver's code must be designed to run on several processors at the same time. Drivers written for MS-DOS and Windows 3.1 are not compatible with Windows NT because they are not designed to run in a multiprocessor environment.

Because drivers can run on multiple processors, drivers must synchronize their accesses to shared resources (data structures or devices). (Recall the synchronization example from the multitasking lesson.) The Windows NT kernel provides mechanisms that help drivers synchronize their actions across multiple processors. Special mechanisms are provided to help synchronize access to resources during the processing of interrupts.

Performing File I/O Without Calling File I/O Functions

In Windows 3.1, when a windows application needs to access data in a file it must open the file, allocate virtual memory to store the data, and copy the data from the disk to the virtual memory piece by piece. Only then can the application process the data. If changes must be saved back to the file on disk, the application must copy the data back into the file piece by piece.

Windows NT's mapped file I/O facilities provide Win32 applications with a simpler and more efficient way to manipulate files. Mapped file I/O allows an application to, in effect, load part or all of a file into its virtual memory space and access it just as it would access a section of ordinary virtual memory. Sections of the file are automatically copied into RAM from the disk when the application tries to access them, so sections that the application never uses aren't loaded from disk. Changes to the memory copy of the file are automatically saved to the disk without any help from the application.

Optimizing The Performance Of The I/O System

The I/O system includes a component called the disk cache manager that helps to increase the I/O system's performance. The disk cache manager retains frequently accessed files in RAM to minimize disk access. The disk cache manager can dynamically grow and shrink its file cache as the amount of available RAM varies. This adaptive caching mechanism provides applications with optimal file I/O performance under whatever conditions occur.

The cache manager normally uses as much physical memory as there is available on the system. As a result, if you were to query to find out how much physical memory is available, the answer may be very low because the disk cache is using all of the available memory. However, should Windows NT need this memory, the disk cache manager will relinquish it. Because of this, the Windows NT program manager's "Help.About..." box no longer displays available memory. (This was true as of the October 1992 beta.)

Before Going On

Before you go on, make sure you can answer the following questions:

  1. What characteristics of the MS-DOS and Windows 3.x device driver architecture forced the development of a new device driver architecture for Windows NT? How does the new device driver architecture address Windows NT's design goals?

  2. How does the uniform layered device driver model make adding file-system capabilities such as striping and mirroring easier?

  3. What is an I/O Request Packet? How are they used?

  4. Draw a diagram of the I/O system that include at least 2 layered drivers and the I/O manager and use that diagram to explain how synchronous and asynchronous I/O requests are processed.

  5. What are the mechanisms by which native Windows NT applications are informed when an asynchronous I/O request is complete?

  6. Identify one benefit of asynchronous I/O over synchronous I/O

  7. What is a benefit of allowing device drivers to be loaded and unloaded dynamically?

  8. What is mapped file I/O? Name two ways in which it's used in Windows NT.

  9. How is disk caching different in Windows NT than in Windows 3.1?

Speaking The Language

This lesson introduced terms that it is important for you to understand. Please look through the list and verify that you understand the meaning of each term:

  • I/O manager

  • I/O request packets

  • Device drivers

  • Synchronous I/O

  • Asynchronous I/O

  • Mapped file I/O

  • Disk cache manager

To Learn More

If you're interested in learning more about this topic, you may find the following resources useful:

  • Inside Windows NT, Chapter 8.