Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1992-03-30
2001-03-06
Chaki, Kakali (Department: 2762)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C703S027000
Reexamination Certificate
active
06199117
ABSTRACT:
DESCRIPTION
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to application programming interfaces (API's) and, more particularly, to API's for starting tasks in accordance with the OS/2™ (trademark of International Business Machines Corp.) operating system.
2. Description of the Prior Art
Central to the useful operation of any data processing equipment is the so-called operating system. The operating system is usually established by software which provides operations that the data processing equipment can then perform in response to commands entered by an operator or in accordance with a program. Numerous successful operating systems have been developed in the past, such as MS-DOS™ (a trademark of Microsoft, Inc.), and UNIX™ (a trademark of Bell Laboratories). Such operating systems establish the basic system operations, including application programming interfaces, which the data processor can perform and the manner in which they are performed within the data processor.
A recently developed operating system which supports a multi-tasking operational mode (e.g. the effectively simultaneous performance of a number of data processing functions) is known as OS/2™. In multi-tasking, different tasks must be designed as distinct executable units which can be performed simultaneously or at least without regard to order among tasks in a particular category. In OS/2™, the basic unit for execution by the data processor is referred to as a thread. A thread also provides a context within which a program or portion thereof corresponding to the thread is to be executed by the processor. This context includes registers, a stack and the CPU mode which will be utilized in executing the thread.
A process is a collection of system resources such as threads, memory, files, devices, pipes, queues, etc. which are allocated to a particular program and must contain a minimum of one thread. OS/2™ also provides so-called sessions which are collections of one or more processes associated with a virtual console which may be constituted by a keyboard, display or mouse. Sessions can, however, be regarded as simply another form of process for purposes of understanding the present invention. As used herein, the term “task” is to be understood as generic to both threads and processes in OS/2™ as well as corresponding types of operations in other operating systems.
There is no hierarchy among threads within a process even though threads can create other threads. Once initiated, a thread is regarded as a peer of all other threads running in the process. Contention for the CPU is normally resolved with respect to particular resources, such as memory or files by the setting and resetting of flags.
A hierarchy can, however, exist among processes and a process may also create other processes. The hierarchy among processes is commonly referred to in parent-child terminology. Between parent and child processes, each containing threads which compete for CPU time, some contention is resolved by providing for suspension of the parent process while the child process executes, such as when the child process is used to generate display of a directory. An example of a process where parent and child execute concurrently would be where the child process prints a file or document in the background while the parent continues to execute, being interrupted briefly from time to time for communication to the printer by the child process.
This hierarchy allows one or more applications programs to be broken down into portions which potentially are simultaneously executable in order to improve system performance. It should be understood that the portions of such applications programs need not be and, in a rigorous technical sense, seldom are, actually performed simultaneously by the CPU of the data processing system. However, dynamically allocating time slots to these program portions and executing them in rapid sequence at the convenience of the processor (e.g. in an order which resolves contention for shared resources) causes the resulting concurrent execution of processes and threads to appear to be simultaneous and greatly improves system performance.
Specifically, when OS/2™ starts a program, it first creates a process to own the necessary resources. Then it loads the program and starts a thread within the process to run the code. As threads from different processes are run, ownership of resources accessible by various threads is established and re-established in accordance with the process. For example, when thread
1
is run in process A, it has access to the resources of process A and when thread
1
is run in process B, it has access to the resources of process B. In this way, contention for shared resources is usually resolved easily. This operation is enhanced by the fact that resources may be dynamically acquired and released from particular processes.
The above and other features of the OS/2™ operating system are detailed in a publication entitled “OS/2 Programmer's Guide”, by Ed Iaccobucci, published by Osborne McGraw-Hill, Inc., 1988, which is hereby fully incorporated by reference for further description of the OS/2™ operating system.
The provision of such a hierarchy of threads, processes and sessions to improve processor performance causes complications in programming because each of these executable types of operations necessarily has a different structure. For instance, within OS/
2
™, any one of four system level application programming interfaces (e.g. DosCreateThread, DosStartSession, DosExecProgram and begin_thread) may be required to start a thread or process. A comparable number of other system level application programming interfaces (API's) would be required in other operating system application architectures capable of multi-tasking operation.
Each operation which may be contained in a thread must cause appropriate operation of the system application architecture (SAA) on which it is to be performed. Since different system application architectures (SAA's) such as MVS, VM, OS400, and other operating systems handle allocation of and contention for shared resources in different ways, the codes required for starting a thread must differ and are typically handled by different application programming interfaces. The required differences are not trivial and may each require from five to fifty lines of code per API.
These different methods of starting a thread impose a severe burden on a programmer who must be familiar with the different parameters and permissible values thereof required for each of these system level API's including the code for each and the different parameters and syntaxes peculiar to each of them. In the course of a particular process, at least one of these methods must necessarily be included. In the course of a program, each may be included numerous times. Further, the inclusion of such code into a program may preclude that program from being executed on a system running a different operating system since the required code for corresponding operating system level API's is very likely to be different. Therefore, the difference of operating system level API's effectively prevents the porting of programs between operating systems. This limitation is a severe one as larger networks are implemented which may include data processors which are running different operating systems. Further, full exploitation of the data processing resources of the entire network is impossible when the execution of a particular program or application is limited to only the processors of the network which have a common operating system.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide a single generalized and simplified applications processing interface which can invoke any one of a plurality of intended operating system application programming interfaces for the purpose of executing work on the processor (e.g. starting a session, process or thread).
It is another object of the invention to prov
Cox Daryl
Gabbard John
Zuponcic Sally
Chaki Kakali
Duffield, Esq. Edward H.
International Business Machines - Corporation
McGuireWoods LLP
LandOfFree
Generalized control for starting of tasks (processes and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Generalized control for starting of tasks (processes and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Generalized control for starting of tasks (processes and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2438545