INPUT/OUTPUT

Requirements for Parallelism and Synchronization

The requirements for· parallelism and synchronization in the I/O subsystem may include any of the

following: .

• The application procedure that requests a READ operation may run in parallel with the I/O subsys-tem until that procedure needs to reference the requested data, at which point it must wait until the data arrives or an exception occurs.

• . The procedure that requests a WRITE operation can usually run in parallel with the I/O'subsys-tem. Some applications require acknowlegement of the completion ofa WRITE operation (in order, for example, to synchronize with a database recovery system), in which case that procedure must wait until the acknowledgement arrives.

• SEEK operations normally run in parallel with the requesting procedure.

• The I/O dev'icecan always run iii parallel with some task in a multitasking system, whether it be the task that requested the I/O operation or some other task that is not waiting for I/O.

• In a simple I/O subsystem in which a device driver onlym~nages one I/O operation at a time, the driver can simply wait until the device signals that the operation finishes. If the requesting proce-dure is blocked, the device driver can merely convert the I/O-complete signal into a wake-up signal

for that procedure. . . . .

• In a more sophisticated I/O 'subsystem (for example, one in which a disk driver handles more than one spindle and more than one task can share a disk device), greatest efficiency results only when device drivers run in parallel with I/O devices as well as with requesting procedures. An 1/0-complete signal from a device may arrive when the device driver is busy.

Figure 8-1 explains the symbols used in a Petri net graph. Figures 8-2 and 8-3 use Petri net graphs to illustrate two approaches to synchronization between parts of an I/O subsystem. A horizontal line represents an event of interest that occurs only under certain conditions. Circles preceding an event represent the conditions under which the event can occur. Circles after an event' represent the condi-tions that result from occurrence of the event. A dot inside a circle is called a token. A token represents

!1condition that is in effe<:t. An event occurs if and only if there are tokens for all its input conditions.

When aneven,~ occurs: tokens flow into all its output conditions.

Figure 8~2 assuines fhesimple device driver mentioned previously and points out how such a driver can service only one task at a time. Figure 8-3 shows how a two-part driver can deal with more than one I/O request at a time (assuming that the I/O device can do so as well). I/O requests from applications procedures drive part A, while interrupts drive part B. Not shown by the Petri net graphs is the fact that the two parts of the driver must share information about outstanding I/d requests. Both figures show simplified device drivers to highlight the interactions among parts of the I/O subsystem; for.

example, a real device driver may issue multiple physical I/O commands in response to one I/O request and may retry I/O operations in case of certain error indications from the device.

Requirements for Protection

The requirements for protection in an I/O subsystem include (in addition to the protection considera-tions previously discussed)

• Device allocation tables and any other data used by the primary I/O interface procedures must be protected from all but those procedures privileged to do I/O, but must be available to every task in which the I/O interface procedures can run.

• Only the device driver should have access to a device's control parameters (for example, head settling time for a disk drive).

8-4 121960-001

INPUT /OUTPUT

• Only the operating system and the I/O subsystem should use queues of buffers and I/O requests.

• An application procedure must not use a buffer that an I/O device is simultaneously using.

Implementation Alternatives

If descriptors for data global to the I/O subsystem (such as device allocation tables) reside in the GDT with DPL equal to the I/O privilege level, then I/O procedures can access them regardless of what

o

o

CONDITIONAL EVENTS

ENABLED CONDITIONAL EVENTS

t t

OCCURRENCES OF EVENTS

121960-39

Figure 8-1. Petri Net Graph Symbols

APPLICATION

REQUEST 110

CONTINUE PROCESSING DO OTHER PROCESSING

RECEIVE RESPONSE

APPLICATION

REQUEST I/O CONTINUE PROCESSING DO OTHER PROCESSING

RECEIVE RESPONSE

INPUT /OUTPUT

DEVICE DRIVER

HARDWARE I/O DEVICE

GET COMMAND

• WAIT 001/0

CAUSE INTERRUPT

121960-37

Figure 8-2. Synchronization with Simple Device Driver

APPLICATION

REQUEST 1/0 CONTINUE PROCESSING DO OTHER

PROCESSING RECEIVE RESPONSE

APPLICATION

REQUEST I/O CONTINUE PROCESSING DO OTHER PROCESSING

RECEIVE RESPONSE

DEVICE DRIVER (PART A)

HARDWARE I/O DEVICE

GET COMMAND

CAUSE INTERRUPT

00110

121960-38

Figure 8-3. Synchronization with Two-Part Device Driver

8-6 121960-001

INPUT /OUTPUT

task the I/0 procedures run in. The I/O interface procedures (READ, WRITE, etc.) must have DPL equal to that of the global I/0 data and therefore must have call gates at the privilege level of appli-cation procedures (PL 3). If these call gates reside in the LDTs of application tasks, then I/0 interface procedures can be shared by (but limited to) those tasks that need them. The call gates can also reside in the GDT, where all tasks can access them. In either case the interface procedures run in the calling task.

The possibilities for running device drivers in parallel with the calling task suggests that they be separate tasks. Such a separation also serves to protect applications and device drivers from one another, a definite advantage because inherent complexity and frequency of change tend to place device drivers among the least reliable of operating system functions. The I/0 interface procedures have the respon-sibility for managing the details of communication between the calling task and the device drivers.

You can implement a sophisticated device driver such as that illustrated in figure 8-3 as two cooper-ating tasks: one scheduled by interrupts via a task gate in the IDT, and the other scheduled by I/O requests via an operating-system mailbox facility.

It is possible to implement device drivers as interrupt procedures that run within applications tasks.

Such a structure is advantageous in these cases:

• Efficiency of I/0 is an overriding goal.

• Interrupts may arrive when a driver is busy.

The lack of protection inherent in such a structure becomes apparent, however, when you consider that the driver procedure that fields an I/O-complete interrupt may run as part of a task completely unrelated to the task that originally requested the I/O operation, and must run at PL O.

Viewing the possible implementations of buffers from the perspective of the iAPX 286 architecture, the most pertinent consideration is whether a segment contains just one buffer or several buffers. An approach that uses one segment per buffer has several advantages:

• The protection mechanism of the iAPX 286 (working as it does on segment descriptors) focuses on each buffer individually.

• The selector of a buffer segment serves as a convenient buffer identifier, fitting easily into the aliasing and mailbox schemes outlined in Chapter 5.

You can avoid the potential GDT congestion that may result from having one segment (and therefore at least one segment descriptor) per buffer by storing buffer descriptors in LDTs.

When tasks share buffers (as between an application task and one or more device-driver tasks), you have a choice between

• Leaving the buffer at all times within the address spaces of all the sharing tasks

• Transferring the buffer from the address space of one task into that of another

The mailbox scheme outlined in Chapter 5 easily accomplishes the latter approach. This scheme has the advantage that the application task cannot use the buffer at the same time as I/O is in progress.

The "usage privilege level" (UPL), if set to IOPL, provides additional protection by limiting mailbox access to I/O procedures. The application's requirements for I/O efficiency may, however, preclude use of mailboxes for this purpose.