Electrical computers and digital processing systems: support – Synchronization of clock or timing signals – data – or pulses – Using delay
Reexamination Certificate
1999-10-28
2003-09-30
Lee, Thomas (Department: 2185)
Electrical computers and digital processing systems: support
Synchronization of clock or timing signals, data, or pulses
Using delay
C710S260000, C712S244000
Reexamination Certificate
active
06629252
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates generally to an improved data processing system and in particular to a method and an apparatus for processing operating system interrupts. Still more particularly, the present invention provides a method to create delays for interrupt handlers at the interrupt system level.
2. Description of the Related Art
An operating system (OS) is essential for any general-purpose computer. The OS provides the fundamental layer of software between the user or application programs and the computer hardware. Some of the services provided by a typical operating system are program execution, input/output (I/O) operations, file-system manipulation, communications, error detection, resource allocation, accounting, and protection.
An operating system is a large, complex program that provides a large variety of services. The entire program need not be resident in memory at all times. However, there is a small kernel that is always resident in main memory. It does not run as a thread, i.e. a stream of execution, and so it cannot be pre-empted. It cannot be paged out to disk, that is, it cannot be removed from memory and written to the swap space on a disk. The kernel contains the most frequently used functions in the operating system, including thread scheduling, process switching, exception and interrupt handling, and multiprocessor synchronization.
The exact details of the interrupt handling mechanism are dependent on the specific computer architecture. However, for a wide variety of architectures, a vectored interrupt scheme is used. Each device that can cause an interrupt is assigned a unique number, and a table is built with the address for the first instruction in the interrupt service routine for each of the devices. When an interrupt occurs, the current instruction of the running process is completed, and the processor acknowledges receipt of the interrupt. A minimum amount of information, e.g., the processor status word (PSW) and the program counter (PC), is saved for the current process. The starting address for the interrupt service routine is loaded from the interrupt vector table into the program counter, and execution of the interrupt service routine commences. Depending on the resources needed by the interrupt service routine, e.g., the need for registers, additional data from the interrupted process may be saved. After the interrupt is serviced, the processor state for the interrupted routine is restored and control is transferred back to that routine once the previous PSW and PC values are reloaded.
Hardware interrupts come from many sources, including, but not limited to, program interrupts (e.g., divide by zero error, illegal instruction, etc.), timer interrupts based on a built-in timer, input/output interrupts to signal completion of an input/output operation, and hardware failure interrupts (e.g., power failure, parity error, etc.). Software interrupts, often called traps, are used by application programs to request a service to be performed by the operating system. It can be seen that interrupts handle both abnormal situations, e.g., power failure, and normal situations, e.g., completion of I/O.
Several issues related to interrupts must be considered, such as whether all interrupts have equal priority. From the range of situations outlined above, it is evident that some interrupts, such as power failure, have much higher priority than other interrupts, such as completion of input/output. Modern systems establish a hierarchy of interrupt priorities and allow a higher priority device to interrupt the service routine for a lower priority device.
Another important consideration is the time it takes to perform an interrupt task switch. This is the time between the invocation of the main interrupt routine, which processes and routes all interrupts, and the execution of the first instruction associated with an interrupt handler for a particular interrupt being serviced. If the interrupt service routine invoked by the interrupt handler can service the interrupt in a reasonably short time compared with the time for an interrupt task switch, then it is most efficient to keep other interrupts masked and complete the interrupt service routine. If the time for the interrupt service routine is considerably longer than the time for the interrupt task switch, it may be desirable to unmask interrupts so that higher priority devices can be serviced. To support this capability, the interrupt service routines have to be made reentrant, i.e. an interrupt service routine needs to save state if a higher priority interrupt is received and be able to resume, once the higher priority interrupt has been serviced. Writing reentrant code adds complexity to the interrupt service routine and has a negative influence on system performance.
It is sometimes necessary to delay the start of an interrupt service routine or to wait to perform some type of processing within the interrupt service routine in order to determine the status of other system devices. This status information is then used to determine the proper action to be performed by the interrupt service routine. In other circumstances, it may be necessary to allow some other higher priority interrupt operation to be performed before the pending interrupt service routine is processed. In circumstances such as these, it would be advantageous to have a method and mechanism to be able to delay processing within an interrupt service routine without having to write reentrant code that saves and restores its execution state and at the same time allow servicing of any higher priority interrupts if they were to occur.
SUMMARY OF THE INVENTION
A method and system for servicing an interrupt is presented. An interrupt handler associated with a detected interrupt is invoked, and a determination is made as to whether to instantiate a delay before further servicing of the detected interrupt. If a delay is necessary before the detected interrupt may be fully serviced, a delay counter is initialized to a first predetermined value in which the initialization value is predetermined such that a minimum time period will elapse while the interrupt remains pending. The interrupt handler then exits without fully servicing the detected interrupt or without clearing the interrupt, i.e., the interrupt remains “hot”. The data processing system may immediately service other interrupts, but because the interrupt remains pending, the interrupt handler associated with the uncleared interrupt is again invoked. During subsequent invocations, the interrupt handler decrements the delay counter and checks whether the delay counter has reached a second predetermined value. If not, the interrupt handler again exits without clearing the interrupt. The interrupt handler is repeatedly invoked while the interrupt remains pending and while the delay counter does not equal the second predetermined value. In response to a determination that the delay counter equals the second predetermined value, the interrupt handler may then fully service the interrupt and clear the interrupt.
REFERENCES:
patent: 4162526 (1979-07-01), Gass et al.
patent: 5708817 (1998-01-01), Ng et al.
patent: 5822595 (1998-10-01), Hu
patent: 5862389 (1999-01-01), Kardach et al.
patent: 5881296 (1999-03-01), Williams et al.
patent: 04195539 (1992-07-01), None
Fawaz et al, Analysis of interrupt handling schemes in real-time systems, 1989 IEEE, Department of EECS University of California Berkeley, California 94720.
Gholami Ghadir Robert
Mehta Chetan
Upton John Daniel
Lee Thomas
McBurney Mark E.
Suryawanshi Suresh K
Yee Duke W.
Yociss Lisa L. B.
LandOfFree
Method for determining if a delay required before proceeding... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for determining if a delay required before proceeding..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for determining if a delay required before proceeding... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3008329