Browse Prior Art Database

Algorithm to Implement Multi-threaded Fairness for a Single Threaded SCSI Controller

IP.com Disclosure Number: IPCOM000107595D
Original Publication Date: 1992-Mar-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 2 page(s) / 136K

Publishing Venue

IBM

Related People

Ruzek, G: AUTHOR [+3]

Abstract

Disclosed is a method for using queues, programmed chip interrupts, and the SCSI (Small Computer System Interface) protocol to implement multi- threaded fairness for multiple SCSI devices connected to the same single-threaded SCSI controller. In this method, commands waiting to execute may preempt others that are already executing.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 47% of the total text.

Algorithm to Implement Multi-threaded Fairness for a Single Threaded SCSI Controller

       Disclosed is a method for using queues, programmed chip
interrupts, and the SCSI (Small Computer System Interface) protocol
to implement multi- threaded fairness for multiple SCSI devices
connected to the same single-threaded SCSI controller.  In this
method, commands waiting to execute may preempt others that are
already executing.

      The definition of a single-threaded SCSI controller implies
that the hardware controlling the SCSI protocol between the initiator
and target only services one SCSI command at a time.  Thus, requests
from other devices wait until the current SCSI command completes.  A
multi- threaded SCSI controller is able to handle requests from
multiple devices.  This does not imply that the different SCSI
commands are issued to the target devices at the same time. Rather,
the SCSI controller is intelligent enough to recognize opportunities
for bus access and grants SCSI bus access to waiting devices.  The
quick multiplexing between waiting and active devices makes the chip
seem like it is executing all SCSI commands concurrently.

      Currently, two methods are used to implement multiple target
device support on a single-threaded hardware controller.  For each
SCSI command, a unit of microcode is generated by the SCSI device
driver controlling the SCSI chip.  The first method involves chaining
together the many SCSI requests (through their microcode) from all
target devices.  One microcode instruction set starts execution upon
the completion of the previous SCSI command.  The second method
requires the inter-chaining of the SCSI microcode modules.  During
the logical breaks in the SCSI protocol, other SCSI command microcode
units are linked into the body of currently executing piece of
microcode.  In both cases, there is no direct involvement by the
device driver when the command links switch from one device to
another. The device driver performs the linking of the microcode and
then leaves the chip to cross the link and begin execution of the new
code.

      There are problems with the two described methods of multi-
tasking. For the first case involving separate chaining of the SCSI
commands, the device driver must decide how many links constitute a
set of commands before it begins execution.  Devices may wait for
commands to other devices to be received by the device driver before
they can execute as part of the chain.  With the second case, the
device driver is patching jumps in between sets of microcode during
dynamic execution of the microcode. There is no guarantee that the
link patch will take effect before the SCSI chip arrives at a
potential link point.  Thus, linked commands may never execute
because the chip has missed the jump to them.  In both cases, a
potential for job starvation exists. If a particular SCSI command
takes a long time to complete (such as a tape rewind), the waitin...