Reentrant and Concurrent Routines

To correctly implement synchronization in your driver, you need to know which driver routines are reentrant and which can run concurrently. Most standard driver routines are both reentrant and concurrent.

Reentrancy

A routine is reentrant if the same copy in memory can be shared by more than one user. Reentrant routines do not maintain static data between calls; all data is provided by the caller of the function. Any caller-specific data that the routine maintains must be stored in an area specific to that call.

Most standard driver routines are designed to be reentrant. For example, in a driver’s I/O dispatch routines, call-specific data is maintained in each individual IRP and passed from one driver to the next. Each driver must either complete the IRP or mark the IRP pending before passing it to the next driver on the stack. Only the DriverEntry and Unload routines are not reentrant.

Concurrency

Two routines that can run at the same time are said to be concurrent. For a driver, concurrency generally means that the operating system (usually the I/O or PnP manager) might call one routine before a previously called routine has completed. For example, the system could call a driver’s Cancel routine while its DispatchRead routine is running.

When two routines can run concurrently, you must ensure that any shared, writable data is accessed by only one routine at a time unless all such accesses are read-only. The data might be in a shared memory buffer, in the device extension, or in a global variable. This means you must use locks, interlocked routines, or some other synchronization technique to prevent conflicts.

Some drivers manage more than one device; others can perform I/O on more than one file at a time. Windows typically calls the standard driver routines to perform a specific task on behalf of a particular driver object, device object, or file object. Whether Windows calls two routines concurrently thus depends on the driver, device, or file objects that each such routine uses. For example, the system might call a driver’s DispatchPnp routine to handle an IRP_MN_REMOVE_DEVICE request for one device while the same routine is handling an IRP_MN_START_DEVICE request on behalf of another device, because the two requests affect different device objects. However, the system would not call these routines concurrently if the two requests were targeted at the same device.

Tables 2, 3, and 4 in the following sections list the concurrency of standard driver routines with respect to driver objects, device objects, and file objects. Refer to the tables to find out whether the operating system calls two routines concurrently with the same object. In the tables:

· Yes means that the system might call the routine listed at the top while the routine at the left is running.

· No means that the system does not call the routine listed at the top while the routine at the left is running.

· Maybe means that whether the routines can run concurrently depends on how the driver is implemented. For example, whether a particular worker thread routine can be called concurrently depends on what the worker thread does.

For example, in a driver that manages two or more devices, the StartIo routine for one device can run concurrently with the DispatchRead routine for another device. However, if the two requests target the same device, these two routines cannot run concurrently. Thus, the StartIo and DispatchRead routines are concurrent with respect to the driver object, but not with respect to the device object.

Date: 2015-12-24; view: 717