Patent Application
20080155235
1. Technical Field
The present invention relates to ucontext functions in general, and in particular to a set of instructions for providing ucontext functions. Still more particularly, the present invention relates to a set of instructions capable of preventing incorrect usage of ucontext functions in a multi-process environment.
2. Description of Related Art
The UNIX® operating system provides a set of functions for handling context. Those context handling functions are often referred to as “ucontext” functions because they are provided via an ucontext.h file.
Specifically, the UNIX® operating system provides four ucontext function instructions, namely, getcontext, makecontext, setcontext, and swapcontext. The four ucontext function instructions may be modified for use in a kernel environment by multiple kernel processes that share the same code segment and address space. Because multiple processes can share the same code segment and address space, the same contexts may be utilized by more than one process.
The potential problem with one context that is capable of being executed by different processes at different times is that harmful and stealthy bugs may be inadvertently introduced in a code segment by a programmer who incorrectly uses ucontext function instructions within the code segment. Consequently, it would be desirable to provide a method for preventing incorrect usage of ucontext functions in a multi-process environment such that debugging effort can be minimized.
In accordance with a preferred embodiment of the present invention, during an execution of a setcontext instruction, a determination is made whether or not a contextID of a context structure associated with a next context indicates that it is an original context of a process. If the contextID of the next context structure is not an original context of a process, the next context for the process is set by loading registers with values from the context structure associated with the next context. However, if the contextID of the next context structure is an original context of a process, another determination is made whether or not the contextID of the context structure associated with the next context is the same as the original contextID of the process. If the contextID of the context structure associated with the next context is the same as the original contextID of the process, the next context for the process is set by loading registers with values from the context structure associated with the next context. Otherwise, if the contextID of the context structure associated with the next context is not the same as the original contextID of the process, an error recovery routine is invoked.
All features and advantages of the present invention will become apparent in the following detailed written description.
The invention itself, as well as a preferred mode of use, further objects, and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
Referring now to the drawings, and specifically to
Computer 100 is capable of communicating with a server 150 via a network 128 using network interface 130. Network 128 may be an external network such as the Internet, or an internal network such as an Ethernet or a Virtual Private Network (VPN).
As utilized herein, a context refers to the current values of all registers within processor 104, and a context structure refers to a data structure within system memory 136 having multiple fields that may be used to store the value of each register within processor 104 at a given point in time. A context can be stored in a context structure having a stack pointer and user registers of a thread.
In accordance with a preferred embodiment of the present invention, a new set of ucontext function instructions that are capable of preventing incorrect usage of ucontext functions in a multi-process environment is provided. The new ucontext function instructions include getcontext, makecontext, setcontext, swapcontext and mycontextID.
The getcontext instruction is identical to the getcontext instruction provided under the UNIX® operating system.
As for the makecontext instruction, a new context identification (contextID) is assigned to the context being created when the makecontext instruction is executed, in addition to the intrinsic functionalities provided under the UNIX® operating system.
The setcontext instruction is also outfitted with additional functionalities in conjunction with the intrinsic functionalities provided under the UNIX® operating system. With reference now to
Otherwise, if the contextID of a next context structure is an original context of a process, then another determination is made as to whether or not the contextID of the context structure associated with the next context is the same as the original contextID of the process, as depicted in block 240. If the contextID of the context structure associated with the next context is the same as the original contextID of the process, then the next context is set for the process by loading registers with values from the context structure associated with the next context, as depicted in block 220. Otherwise, if the contextID of the context structure associated with the next context is not the same as the original contextID of the process, then an error recovery routine should be invoked, as shown in block 250, because an incorrect context setting has occurred due to an incorrect of the setcontext instruction.
In most applications, a swapcontext instruction uses a setcontext instruction. When a setcontext instruction is called by a swapcontext instruction, the above-mentioned functionalities are also included in the swapcontext instruction.
The mycontextID instruction returns a contextID each time it is executed.
As has been described, the present invention provides a set of ucontext instructions that is capable of preventing incorrect usage ucontext functions in a multi-process environment.
It is also important to note that although the present invention has been described in the context of a fully functional computer system, those skilled in the art will appreciate that the mechanisms of the present invention are capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing media utilized to actually carry out the distribution. Examples of signal bearing media include, without limitation, recordable type media such as floppy disks or compact disks and transmission type media such as analog or digital communications links.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
