Data processing: structural design – modeling – simulation – and em – Simulating electronic device or electrical system – Software program
Reexamination Certificate
1998-12-16
2001-12-11
Teska, Kevin J. (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Simulating electronic device or electrical system
Software program
C703S021000, C703S026000, C703S023000, C717S152000, C714S002000, C714S015000, C714S028000, C714S034000
Reexamination Certificate
active
06330528
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates generally to computing systems that allow multiprocessing, specifically, the invention relates to a method that allows processes to be terminated by other processes, particularly in multi-threaded environments.
When a number of processes are concurrently executing in a multiple process environment a need can arise to force termination of one or more of those processes. For example, a process may “hang,” i.e., experience an error that causes it to halt without terminating, or to enter an endless loop. In such instances it is desirable to end the errant process rather halt all processes and bring down the entire system. Thus, operating system functions are provided that allow a process to terminate another process.
The process need not necessarily be errant. There may also be instances, such as a panic shutdown, to halt or otherwise terminate a process. However, if the process requested or desired to be terminated is, at the time the request or desire is acted upon, performing some system critical operation (e.g., performing a write to (disk) storage), there is a chance that system data or a database or some other data structure can be corrupted. For this reason processes are often given the opportunity to prohibit being stopped until a system critical operation has completed.
When it is wanted to “port” such processes to other environments, problems concerning the capability of allowing a process to stop another process are encountered. Application programs are normally written to create processes that run on specific systems and in conjunction with a specific operating system that performs supervisory control of system resource allocation (e.g., allocation and usage of such system resources as memory, processing time, disk space, peripheral devices, and the like). Use of these processes over time verifies their credibility and operability. The more useful processes become the objects of “porting,” i.e., the transfer of the programs to an operating system different from that application originally intended. This will typically require that the application program be rewritten for the new operating system, and if the new operating system is substantially different, or the program language in which the process was originally developed is particularly difficult for the new operating system, the porting task can become a tedious. Such porting procedures can, therefore, be time consuming and expensive, depending upon the process, the structure of the old and new operating systems, and other reasons not necessarily relevant here. For this reason, it may be desirable to simulate the old operating system in the new operating system environment so that the process being ported does not need to be substantially revised—if at all.
However, simulating an operating system in order to allow porting of a process or processors may carry with it additional problems. One such problem concerns the necessary cleanup of system resources (e.g., removal of data structures, deallocation of memory, etc.) obtained by a process while running. For example, normally an operating system controls the “stack” (i.e., that data structure used by the operating system to contain status data for running processes), and the cleanup of a process is done by the process that is terminating by calling a re-entrant routine that uses services of the operating system and its access to the stack. However, when a process has been ported from a foreign operating system environment to run in conjunction with a simulated version of the foreign operating system (hereinafter “Simulated Operating System” or “SOS”) the usual cleanup most likely will not be available in the present or “native” operating system on which the Simulated Operating System runs. Also, there may be code in the Simulated Operating System that would be beneficial to use in the Native Operating System environment.
Porting to other operating systems also created problems in connection with process stopping—particularly in distributed and/or multi-thread environments. For example, suppose process A wishes to stop process B. The stop request will be sent to the service of the simulated operating system which will check the stop mode of the target process, process B (i.e., whether it has made itself unstoppable in order that it complete some system critical task). If the check indicates the process is stoppable, the service will spawn a thread that, in turn, will attempt to stop the target process. But, there is a chance that a thread of the target process raises the stop mode of the target process in order to create a system critical task before the service completes its task of stopping the target process. Thus, the target process will either be stopped in the midst of a task, resulting in possible data corruption, or the target process will continue while the process A believes it has stopped.
It can be seen therefore, that a technique for allowing one process, running in a multiprocess and/or, in particular, a multi-threaded environment, to terminate another process even if the process to be terminated is running in an unstoppable mode.
SUMMARY OF THE INVENTION
According to the present invention, processes running in a multiprocess and/or multi-threaded environment are given the power to stop or otherwise terminate other processes, provided the processes to be terminated are stoppable. If the processes to be terminated are not stoppable, a data field will be set so that when a process comes out of it non-stoppable mode, it will check the field to determine if an attempt has been made to terminate it. If so, the process will terminate itself.
In the preferred embodiment of the invention, when a process is created, a data structure (“Process Control Block” or “PCB”) is also created and associated with the newly-created process. The PCB contains information concerning the process, and is stored in a common memory shared with other processes. Information kept in this common memory, such as the PCB for each process, is accessible to all processes then (concurrently) executing.
A process' PCB has two integer value fields for implementing the present invention: a StopMode field, and a Qstop field. The StopMode field is set when the corresponding process wishes to make itself unstoppable to protect a critical operation or operations, such as writes to a database. If, while in an unstoppable mode, an attempt to terminate the process is made, that attempt will be noted by setting the Qstop field. When the process completes its (protected) critical task, it will clear the StopMode field and check the Qstop field. If the Qstop field indicates that an attempt has been made to terminate or stop the process, the process will terminate itself.
The invention is preferably implemented in the context of a process that is ported from an operating system environment for which it was originally designed to a different operating system. The porting operation involves simulating the original operating system (hereinafter the “Simulated Operating System” or just “SOS”) to run on the new (different) operating system (hereinafter the “Native Operating System” or just “NOS”). The processes ported from the original operating system run in conjunction, and under the supervision, of the SOS in the NOS environment. In addition, the particular NOS used permits not only a multiprocess environment, but a multi-threaded environment, i.e., each process may have a number of concurrent threads executing.
According to the present invention, when a thread is spawned to execute under supervision of the SOS and in the NOS environment, it will increment the StopMode field to enter an unstoppable mode, and decrement the StopMode field when that same thread leaves the unstoppable mode. Requests to stop or terminate a process are processed by the SOS, which will first suspend all threads of the process requested to be terminated, and check the StopMode field. If the StopMode field is not of a predetermined value (e.g., zero), the process is u
Huang Cheng-Yu
Jere Siddhesh
Merrick Jeffrey D.
Saoji Sudesh
Boyce Justin
Compaq Computer Corp.
Oppenheimer Wolff & Donnelly LLP
Sherry Leah
Teska Kevin J.
LandOfFree
Method of terminating temporarily unstoppable code executing... 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 of terminating temporarily unstoppable code executing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of terminating temporarily unstoppable code executing... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2586455