Electrical computers and digital processing systems: multicomput – Computer network managing – Network resource allocating
Reexamination Certificate
1998-12-29
2002-12-17
Banankhah, Majid A. (Department: 2156)
Electrical computers and digital processing systems: multicomput
Computer network managing
Network resource allocating
C709S241000, C709S205000, C709S206000, C709S223000, C709S238000, C709S239000
Reexamination Certificate
active
06496864
ABSTRACT:
BACKGROUND OF THE INVENTION
1. The Field of the Invention
This invention relates to systems and methods for freeing shared resources in a computer system. More specifically, the present invention relates to systems and methods for freeing shared resources that have been allocated to a process that has terminated without freeing resources allocated to it.
2. The Prior State of the Art
When personal computers were first introduced, the operating systems were fairly rudimentary and only provided for a single task or process to run on the computer at any given time. This process had complete access to all system resources when it was running and could generally directly access any of the hardware devices on the computer. For example, many processes wrote directly to the display hardware to display information to a user. Because the process was the only process trying to access the display device, writing directly to the display device produced few problems and generally resulted in good performance even though these early personal computers had relatively little computing power.
One unfortunate drawback of directly accessing the computer hardware is that the program expected to see a particular type of hardware. This typically did not create any problems as long as most computers had identical hardware. For example, early computers offered very few choices with regards to the type of display device. As technology increased, however, the types of display devices available have proliferated and users today seem to have an almost limitless choice of display devices. If a process is going to write directly to the display device, the process must be able to operate with many, if not all, of the various display devices that are available. This can create enormous problems for computer programs that are created for wide distribution. Display devices are not the only hardware devices where these types of problems can arise. Other computer hardware may also present similar problems if a program attempts to directly access the hardware.
In order to eliminate the direct dependence on hardware, methods have been developed to allow a process to access a piece of hardware in a “device independent” manner. Essentially, this means that a process can access a particular type of hardware device in a manner that is essentially consistent from one hardware device to another. For example, if a program is to access a display device it would be desirable to allow the program to access any type of display device in substantially the same manner without having to worry about the particular hardware details of each individual display device. In order to provide a consistent interface between a process and a particular type of hardware device, there may be several abstraction layers between the actual hardware and the process.
FIG. 1
contains an illustration of one method for allowing a process device independent access to hardware.
In
FIG. 1
, the actual hardware is illustrated by hardware
10
. This hardware is often referred to as a “hardware layer.” Hardware
10
represents the actual system hardware itself, such as a display device with its accompanying adapter card or a disk drive controller. On top of the hardware layer is often a “driver layer.” In
FIG. 1
, the driver layer is illustrated by hardware driver
12
. The driver layer is typically responsible for interfacing directly with the hardware and provides a set of interface functions that allow low level access to hardware
10
. The driver layer hides device details by taking device independent requests and converting them to hardware specific requests. In other words, the driver layer provides a standardized or consistent set of functions that allows access to a particular type of hardware device in a substantially consistent manner independent of the actual hardware device used. Interfacing with hardware driver
12
is an application program interface layer or “API layer.” The API layer enhances the ease of use of the driver layer. The API layer can provide parameter validation and error checking to filter bad requests from processes. The API layer may also implement higher level services on top of the driver layer in order to add additional functionality. In
FIG. 1
, the API layer is illustrated by application program interface
14
. As illustrated in
FIG. 1
, process
16
uses application program interface
14
to access hardware
10
through hardware driver
12
. Together, hardware driver
12
and application program interface
14
allow process
16
to access hardware
10
in a device independent manner so that the hardware details are hidden and the interface remains substantially constant independent of the actual hardware used.
Accessing hardware in a device independent manner overcomes the drawback of requiring a process to be written specifically for a particular type of hardware and allows a single process to function with a wide variety of hardware devices. Another problem that has arisen due to advances in technology is the need to share single hardware devices among a plurality of processes. In the early days of personal computers, the hardware and operating systems were designed to allow a single process to run on the computer at any given moment. However, today's operating systems often allow several processes to appear to run simultaneously on a single computer. This capability, known as multitasking, requires multiple processes on a single computer to share common hardware. For example, for computer systems that have only a single display device, if two processes are running simultaneously on the computer, then each may need access to the display device. This creates a situation where the display device must be shared among multiple processes. Similar requirements exist for other types of computer hardware such as input devices like keyboards, a mouse or other pointing device, or another type of input device, mass storage devices such as disk drives, and other hardware that may need to be shared among multiple processes.
To accommodate such shared access to various hardware devices while maintaining device independent access to hardware, the model presented in
FIG. 1
can be extended. For example, hardware layer
10
can become a shared hardware device. Hardware driver
12
may become a shared hardware driver, and application program interface
14
may become a shared application program interface. Referring now to
FIG. 2
, these three layers are illustrated as shared hardware layer
16
, shared hardware driver layer
18
, and shared API layer
20
. As indicated in
FIG. 2
, these layers are shared among a plurality of processes. For example, shared hardware layer
16
may represent a common display device that is shared by multiple processes. Shared hardware layer
16
is accessed through shared hardware driver layer
18
which, like its counterpart in
FIG. 1
, generally provides a set of functions that allows low level access to shared hardware layer
16
. Finally, shared API layer
20
provides a device independent interface for the multiple processes that share the hardware.
In
FIG. 2
, the hardware is shared by two processes, process A, indicated generally as
22
and process B, indicated generally as
24
. Since shared API layer
20
, shared hardware driver layer
18
, and shared hardware layer
16
must be shared between a plurality of processes, such as process
22
and process
24
, it may be desirable to map shared API layer
20
, shared hardware driver layer
18
, and shared hardware layer
16
into the address space of both process
22
and process
24
. This is indicated in
FIG. 2
by showing shared API layer
20
, shared hardware driver layer
18
, and shared hardware layer
16
as part of the shared address space. Anything in the shared address space is literally shared between both processes. For example, shared API layer
20
can be seen and accessed both by process
22
and process
24
. This is because shared API layer
20
, as well as the other shared layers, are mapped into the address spa
Banankhah Majid A.
Microsoft Corporation
Workman & Nydegger & Seeley
LandOfFree
System and method for freeing shared resources in a computer... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for freeing shared resources in a computer..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for freeing shared resources in a computer... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2920908