Electrical computers and digital processing systems: interprogra – Device driver communication – Video graphics device driver
Reexamination Certificate
1998-09-10
2004-05-18
An, Meng-Al T. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Device driver communication
Video graphics device driver
C719S323000
Reexamination Certificate
active
06738974
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention generally relates to computer system resource management and more specifically relates to thread management in a multi-threaded programming environment.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware (e.g., semiconductors, circuit boards, etc.) and software (e.g., computer programs). As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computers have increased, the application programs designed for high performance computer systems have become extremely powerful.
One way in which the performance of application software programs has been improved is by using “multi-threaded” programming concepts. In multi-threaded computer programming environments, a single application program or process will typically have multiple sub-processes called “threads.” This means that the application program has a number of smaller tasks, each of which can be processed to completion independently. When a process has multiple threads, then the process is said to be a multi-threaded process. In general, there is less system-level overhead in managing a multi-threaded process as opposed to managing multiple processes to accomplish the same task. This is because, unlike independent processes, multiple threads from the same process will co-exist in the same memory space, thereby reducing memory management tasks. Thus, a certain amount of processing efficiency can be obtained by using threads in a multi-threaded operating system environment. Also, by compartmentalizing the various functions of a process into multiple threads that may be processed in parallel, independent tasks can often be completed in a more expeditious fashion.
While the implementation and use of multi-threaded programming concepts has been mostly beneficial, the use of thread concepts is not without certain limits and, occasionally, undesirable side effects. For example, there is a certain amount of overhead incurred in the computer system as the threads are allocated and tracked by the multi-threaded operating system. Additionally, depending on the allocation of shared system resources among different threads, conflicts in resource utilization can occur. Since many different threads can be processing simultaneously, it is entirely possible that two or more of the threads may need access to a given shared system resource at the same time. However, if a given thread has acquired a resource for use and that thread is terminated unexpectedly for any reason, the acquired resource may become unavailable for other threads, leading to inefficiencies in the processing environment.
For example, a given process running on a thread may be using a shared system resource such as a mutex object. A mutex object is an object that locks a piece of data such that only one thread can control that piece of data at any time. It is a shared system resource because many threads may wish to access the mutex object to get to the piece of data. If the thread is terminated abruptly, such that the thread does not have an opportunity to quiesce its state, the shared mutex object may be “locked-out” and other threads associated with other processes may be unable to access the mutex object, and its concomitant data, for use. This situation may require a complete shutdown of one or more processes to allow the shared resource to be “released” so that the shared resource can be made available for other processes. In another scenario, a process may be “looping” for an extended period of time, using a shared system resource, and thereby preventing other system processes from accessing the shared system resource. In some cases, it may even become necessary to restart the entire system to allow the shared resource to become available for processing again.
In either case, the possible options for solving the problem of obtaining access to a shared system resource are undesirable. If a process or system has to be terminated, there is a significant decrease in overall system performance and a related loss in efficiency, which is also undesirable. However, at present, there are no known solutions for recovering access to shared system resources that have been taken out of operation by a process and its threads, particularly a user-supplied process and its threads, since the overall system will not have control over the usage or allocation of the shared resources controlled by a user-supplied process and its threads.
Therefore, what is needed is a shared system resource allocation and management mechanism for effectively allocating and controlling shared system resources in a multi-threaded environment. Without a mechanism for providing greater control and flexibility over the allocation and management of shared system resources, multi-threaded systems will continue to suffer from significant reductions in productivity and the concomitant loss of profitability when multiple processes need to access and share system-level resources.
BRIEF SUMMARY OF THE INVENTION
According to a preferred embodiment of the present invention, a shared resource registry is created and maintained by the system to control allocation and deallocation of shared system resources. The shared resource registry will contain information regarding the allocation and control of shared system resources. By accessing shared system resources through the shared resource registry, control of the shared resources is vested in the system instead of individual threads. When the system needs access to a shared resource, it can notify the shared resource registry regarding the desired resource and schedule the termination of the thread or process which has acquired the desired resource. The shared resource registry can then release the desired resource and make it available for another process.
REFERENCES:
patent: 4604694 (1986-08-01), Hough
patent: 5754854 (1998-05-01), Kanamori et al.
patent: 5938722 (1999-08-01), Johnson
patent: 6105098 (2000-08-01), Ninose et al.
patent: 6243668 (2001-06-01), Le et al.
patent: 6278691 (2001-08-01), Ohyama et al.
Nageswaran Parthasarathy
Norman Eric Jon Van
An Meng-Al T.
Ho The Thanh
International Business Machines - Corporation
Payne Leslie J.
Schmeiser Olsen & Watts
LandOfFree
Apparatus and method for system resource object deallocation... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for system resource object deallocation..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for system resource object deallocation... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3193101