Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-08-26
2002-04-23
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C710S048000
Reexamination Certificate
active
06378006
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a data processing method that implements device control in an object-oriented operating system. The present invention also relates to a recording medium storing a program that implements the data processing method, as well as to a data processing apparatus incorporating the recording medium. Details of certain features of the present invention are described in European Patent Application No. 0.753,811 A1 entitled “Data processing method and device” and filed by the same assignee on Jul. 12, 1996 claiming a Convention Priority on JP 178625/95, filed Jul. 14, 1997, the complete disclosure of which is hereby incorporated herein by reference.
2. Description of the Related Art
In general, device drivers that are programs for controlling various hardware devices are implemented as part of an operating system, as illustrated in FIG.
8
. More specifically, the operating system, in response to a request for using a certain device driver given by a client or to a hardware interrupt, retrieves a device driver table to find the target device driver complying with the request or the interrupt from among device drivers registered in the device driver table. The operating system then calls the found device driver by means of a function call and executes the called device driver.
The client's request is given by means of a system call, while the hardware interrupt is made by invoking a kernel thread of the operating system.
This known system has the following problems.
(1) Adaptability of the operating system is limited and replacement of a device driver is not easy because the device driver is implemented as part of a kernel of the operating system.
(2) Any error in a device driver affects the whole operating system because the device driver is executed with the same authority as the kernel of the operating system.
(3) Interrupt and other controls are performed on independent device drivers. The programmers who form the device drivers, therefore, are required to have knowledge of the whole system and to consider the influence of each device driver on other parts of the system.
(4) The style of programming of the device driver is significantly different from that for application programs because the device driver is implemented as part of the kernel of the operating system. Therefore, it is not easy for a programmer to form a device driver unless he is familiar with and well trained in the programming style which is used in describing device drivers.
In order to overcome these problems, a method has been known in which device drivers are described by using an object-oriented technique. When the object-oriented technique is used, the device drivers are formed as parallel objects outside the operating system, in the same way as that for application programs, as shown in
FIG. 9
by way of example.
The term “parallel objects” is used in this specification to mean program functions in the form of object modules which are objective entities to be handled by the operating system. Thus, the parallel objects are the units to be handled or processed. For instance, scheduling by the operating system is performed on a parallel-object basis. Communication also is executed on the units of parallel objects. In other words, the objects constitute units for operations such as resource management and exclusive execution. The use of such objects enables a programmer to form an object without requiring knowledge of contents of other objects. Thus, the contents of each object can be determined without taking into account factors such as exclusive control.
The described method relying upon the object-oriented technique has the following two major features.
(1) A request from a client to a device driver is sent in the from of a message from the client to the device driver described as a parallel object, as indicated by “request” in FIG.
9
. Similarly, an interrupt request is sent, as indicated by “interrupt” in the
FIG. 9
, in the form of a message from the operating system to the device driver described as a parallel object.
(2) Each device driver runs with a single thread, and the control of the interrupt mask is performed on independent device drivers. Thus, when a device driver is operating, interrupts to be handled by this device driver are not accepted. This relieves the programmers from the burden of considering exclusive control and other controls to cope with an interrupt when they describe each device driver.
By virtue of the two major features set forth above, device drivers described as parallel objects can be formed in the same way as that for application programs. In addition, replacement of device drivers can easily be carried out because the device drivers are implemented outside the operating system. It is also to be appreciated that the stability of operation of the operating system is greatly improved because an error occurring in one device driver does not affect the entire operating system.
Thus, the described problems encountered with the device drivers implemented as part of an operating system in the manner shown in
FIG. 8
can be overcome by the technique shown in
FIG. 9
in which the device drivers are described as parallel objects similar to application programs.
The technique shown in
FIG. 9
, however, is still unsatisfactory in that a running device driver does not accept any interrupt. A concept termed as “interrupt mask” is used to express the state of the device driver as to whether or not the device driver accepts an interrupt. For instance, the state of the device driver which rejects an interrupt is expressed as “the interrupt mask is closed”. Thus, an expression “interrupt mask is open” means that the device driver is in a state ready to accept the interrupt.
In the technique shown in
FIG. 9
, the interrupt mask is closed when the device driver is running. Consequently, interrupt latency is prolonged when the processing which is being executed by the device driver includes time-consuming work such as copying of data.
Thus, interrupts cannot be accepted when the device driver is running because each device driver runs with a single thread. Hitherto, the only solution to this problem was to shorten the method of each device driver. It has been therefore difficult to describe a device driver which poses a severe restriction of interrupt latency when describing the device drivers in the form of parallel objects.
SUMMARY OF THE INVENTION
Accordingly, an object of the present invention is to provide a data processing method based on object-oriented device drivers and capable of shortening interrupt latency without impairing the advantage offered by the use of the device drivers.
Another object of the invention is to provide a recording medium storing a program which implements the data processing method.
Still another object of the invention is to provide a data processing apparatus incorporating such a recording medium.
To these ends, according to one aspect of the present invention, there is provided a data processing method in which a device driver for driving a hardware device is described in terms of a multi-thread object capable of allocating a message processing thread and interrupt processing threads to be exclusively used for respective interrupts. The device driver assigns to the message processing thread a processing based on a message received by the device driver from another object thereby executing the processing in the message processing thread. When an event has occurred requesting an interrupt to the device driver, the device driver executes an interrupt processing corresponding to the event in a processing thread corresponding to the event, wherein, in case that the corresponding interrupt processing thread is busy due to execution of another interrupt processing in response to another interrupt when the event has occurred, the interrupt processing corresponding to the event is held without being executed regardless of the state of the message processing thread and is
Courtenay III St. John
Frommer William S.
Frommer & Lawrence & Haug LLP
LandOfFree
Data processing method, recording medium and data processing... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Data processing method, recording medium and data processing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Data processing method, recording medium and data processing... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2834206