Electrical computers and digital processing systems: interprogra – Interprogram communication using shared memory
Reexamination Certificate
2001-03-30
2004-12-07
An, Meng-Al T. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Interprogram communication using shared memory
C711S209000
Reexamination Certificate
active
06829769
ABSTRACT:
BACKGROUND OF THE INVENTION
1. The Field of the Invention
The present invention relates to interprocess communication. More specifically, the present invention relates to methods, systems, and computer program products for high-performance interprocess communication that minimizes context switches, kernel transitions, and blocking.
2. Background and Related Art
Various technologies are available for communicating information from one process to another. Among the most well-known technologies for interprocess communication are remote procedure calls (“RPC”), lightweight remote procedure calls (“LRPC”), and components based on COM or DCOM. For the most part, well-known interprocess communication techniques are general-purpose solutions that must satisfy a variety of competing interests. One significant drawback to general-purpose solutions is the need to account for the lowest common denominator, foregoing optimizations that might otherwise be available to a particular implementation. As a result, generic interprocess communication often imposes a substantial amount of overhead that tends to degrade throughput and overall performance. Among other things, interprocess communication may increase blocking, kernel transitions, and context switches, with the effect particularly pronounced when two server processes must communicate frequently in achieving a common goal or task.
Because of the higher overhead that interprocess communication is likely to introduce, programs running on a server are often written as monolithic processes to maximize performance. Nevertheless, dividing a particular task into several well-defined processes may provide a substantial benefit in simplifying program design. In choosing between potential improvements in performance versus potential improvements in program design, however, performance frequently is given more weight because end-users invariably detect slow program execution, whereas internal program design is much more difficult for end-users to quantify.
When multiple processes run concurrently on a single processor, the state information that distinguishes one process from another must be kept separate. Switching from one process to another requires storing the state information for the currently executing process and loading the state information for the process to be executed. The storing and loading of state information is known as a context switch. A context switch does not involve executing the instructions of a particular process to achieve a given goal or task; rather, a context switch is merely preparation for executing the instructions of a particular process. The more time spent switching from one process to another, the less time available for running the processes themselves. Of course, some environments may include excess computing resources or sufficient user interaction such that context switches do not represent a significant burden. In other environments, however, especially environments where one process provides one or more services to other processes, context switches may represent a significant amount of processing time that would boost performance if eliminated or reduced.
One way to diminish the impact of context switches is to shrink the amount of state information that must be stored and loaded. So-called lightweight processes or threads are directed largely toward to goal of minimizing state information and the corresponding performance detriments of context switching. Nevertheless, although reduced in extent, whether context switches involve processes or some type of lightweight counterpart, the execution time required for storing and loading context information diminishes performance. Naturally, as the number of competing processes increases, the amount of processor time devoted to context switching may increase as well. Because many of the issues involving interprocess communication are similar for processes, threads, lightweight processes, etc., the term “process” as used throughout this application should be interpreted as a generic term that encompasses all entities capable execution, including threads, lightweight processes, and the like.
Another factor to consider in evaluating the performance of interprocess communication is the execution time required to marshal data. Data marshaling accounts for system or process differences. For example, the address space of one process may be distinct from the address space of another process, one process may represent data differently from another, etc. Therefore, marshaling generally includes copying parameters, return values, and/or other exchanged data from one process to a shared memory area and then from the shared memory area to another process. As part of the copying, data may be formatted in a portable structure to account for any differences in how the processes represent data. Depending on the data to be exchanged, data marshaling may involve copying, probably multiple times, large amounts of data from one memory location to another. Like context switches, marshaling data is overhead to interprocess communication in which a particular process does not make further progress in achieving its goal or task, but rather, simply prepares for making progress.
At times, one process may need one or more services that another process provides. In using the services of another process, one process often communicates parameters and/or data to the process implementing the needed services and waits for a response. While waiting, the process is “blocked.” Blocking is a mixed bag of sorts. A blocked process does not receive any execution time because it is unable to run. By blocking, the process will not be available for a context switch that, if it occurred, would be followed immediately by another context switch because the blocked process cannot continue further processing until it receives a response. Thus, in one sense, blocking saves unproductive context switches. At the same time, however, blocking virtually guarantees one or more context switches. As soon as a process blocks, another process must be selected to run, resulting in one context switch. Then, at a later time when the blocked process receives its response, another context switch occurs to allow the now unblocked process to continue execution.
To illustrate as least some of the foregoing problems, consider the following overview of LRPC. As indicated above, LRPC stands for local remote procedure call and differs from RPC mostly in its underlying implementation. LRPC is used for RPC calls that stay on the same machine, as automated by the RPC subsystem. Rather than network transfer, LRPC uses shared memory for data transfer.
As a specific example, consider LRPC communication between process A and process B. Process A calls into its side of an RPC handler which marshals its data into shared memory, signals process B to handle the call, and then blocks the thread until process B signals that it has completed the request. Process B wakes up when signaled, unmarshals the shared memory data, and calls the registered function with the unmarshaled parameters. Process B waits for the function to return, marshals any return data into shared memory, and then signals process A that it is done. Process A then wakes up, unmarshals the return data, and the RPC routine returns to the caller. Note that LRPC involves multiple context switches, a significant amount of data marshaling, and synchronous interprocess communication that blocks further process execution.
SUMMARY OF THE INVENTION
The present invention provides for high-performance interprocess communication without the prohibitive overhead that may be imposed by prior art techniques. During an initialization phase, each side dynamically identifies one or more routines that are responsible for handling communication received from other processes. Communication between processes occurs through a shared memory heap and a shared memory queue. Allocations from the shared memory heap produce a process agnostic memory handle and a process specific memory pointer. Using the mem
Cranston Wayne M.
Purtell Michael J.
Yang Min-Yu
An Meng-Al T.
Bross Edward
Microsoft Corporation
Workman Nydegger
LandOfFree
High performance interprocess communication does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with High performance interprocess communication, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and High performance interprocess communication will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3329017