Electrical computers and digital processing systems: interprogra – Interprogram communication using shared memory
Reexamination Certificate
2000-09-29
2004-09-14
Lee, Thomas (Department: 2126)
Electrical computers and digital processing systems: interprogra
Interprogram communication using shared memory
Reexamination Certificate
active
06792604
ABSTRACT:
FIELD OF INVENTION
The present invention relates to interprocess communications (IPC), for transferring data or resource control between processes running in a data processing system or device.
BACKGROUND
There are many instances where interprocess communication (IPC) is required within a data processing system. During the operation of a resource manager computer program such as the MQSeries messaging communication manager from IBM Corporation, IPC is required for transferring data and control from one process to another, while implementing process isolation which separates a process' resources from other processes. The two processes communicating via an IPC mechanism may be, for example, an application program and a process within a resource manager program. (IBM and MQSeries are trademarks of International Business Machines Corporation.)
It is known in the art for an IPC implementation to be re-connectable—i.e. two processes A and B communicate via an IPC link and when one of these processes A has ended its communication with its communication partner process B, another process C must be able to establish a communication with the process B and this must be possible even if the previous communication ended in an uncontrolled manner (e.g. unexpected termination of process A). This ability to re-connect, or reuse the IPC mechanisms, is important since it enables a single locatable name or address to be used for all IPC conversations with a particular process (B in the above example) and avoids having to continually repeat the IPC link creation steps of allocating a shared memory block for the link and allocating any other resources such as semaphores, mutices, etc.
However, the reliance by many re-connectable IPC mechanisms on obtaining mutex locks for every data transfer via the link (to prevent resources being left in an inconsistent and unresolvable state when failures occur) entails a processing overhead which can significantly reduce processing efficiency during normal forward processing. Since most processing does not result in failures, the processing overhead of the known mechanisms for dealing with failures is undesirable and a more efficient yet still re-connectable IPC mechanism is desirable. The alternative is a non-recoverable approach which optimizes processing for the non-failure case and does not enable reuse of the same named link. This is generally unacceptable since it would allow certain failures to have a major impact on processing efficiency.
One known IPC implementation is of a flip/flop design, in which control is handed from process A to process B, process B then passes control back to process A when it has completed its task, and this then repeats. For optimal efficiency this passing of control is implemented by using a pair of semaphores, one owned by each end of the link. To pass control (which we will refer to hereafter as the baton for ease of reference) a process resets its own semaphore then posts (i.e. instructs updating of) the other process' semaphore. On being posted the second process picks up the baton and takes control, and this passing of the baton is symmetrical. The data passed between processes is held in shared memory which both processes can read and write to.
This implementation is IPC in its simplest form, but a problem with this approach is that there is a small time window between resetting one semaphore and posting the other where, effectively, neither process holds the baton. If one of the processes was to fail during this window, a new process wishing to start a conversation with the remaining process would not be able to. The problem is that neither process can take the baton in case the other process is using it, to avoid resource update inconsistencies, and since in this situation neither process has the baton we have a stalemate situation.
SUMMARY OF INVENTION
In a first aspect, the present invention provides a method for recovery from interprocess communication failures, the method comprising: in response to an initiator process requesting interprocess communication (IPC) with a responder process via an IPC link, determining whether the initiator process has write control of the IPC link and setting an indicator if the initiator process does not have said control; a process other than said initiator process checking said indicator and, in response to determining that said indicator has been set, notifying the initiator process to take said control.
The step of setting the indicator may comprise setting a token or otherwise indicating that the initiator process does not have control, so that a separate process can recognize this lack control and take appropriate action. The step of checking whether the indicator has been set is preferably implemented in response to non-establishment of interprocess communications within a preset time period;. The checking step and the step of notifying the initiator process to take control are preferably implemented by the responder process, but alternatively could be implemented by a separate process which manages the link.
The present invention addresses the problem of neither of the initiator and responder processes being able to take control of the IPC link in some circumstances, in case the other process already has control. This arises because of the requirement for atomic resource updates (i.e. updates must not leave resources in an inconsistent state) and can result in a stalemate situation. Known solutions to this problem which use mutex locking for every transfer of write control of the link during normal forward processing are too inefficient in systems which have a high communication throughput.
Using the present invention, a failure to establish communications via an IPC link, which resulted from processes having terminated when neither process has control, can be resolved by the initiator process recognizing situations in which it does not have write control of the IPC link and causing the responder process (or a separate process which manages the link) to also recognize when such situations have arisen. This avoids a potential stalemate situation without compromising the requirement for atomic updates and without reliance on mutex locking of IPC control mechanisms for every transfer of data or control.
In a preferred embodiment of the invention, a method for recovery from interprocess communication failures comprises: creating an interprocess communication (IPC) link for communications between an initiator process and a responder process, including providing a pair of tokens which are each associated with one end of said IPC link; responsive to an initiator process requesting communications via said IPC link, determining whether the initiator process has write control of the IPC link and, if not, incrementing the token associated with the initiator process' end of the link; if said request for communications is unsuccessful (for example, if communications are not established within a set time period), comparing the incremented token with the token associated with the responder process' end of the link to determine whether said tokens are synchronized; if said tokens are not synchronized, notifying the initiator process to take said control and resynchronizing said tokens.
In preferred embodiments of the invention, subsequent to comparing the tokens, the responder process relinquishes control of the link and notifies the initiator process (e.g. by posting a semaphore associated with the initiator), and then subsequently resynchronizes the tokens. The initiator process responds to the notification by taking control of the link. The reason for resynchronizing the tokens subsequent to notifying the initiator process is to avoid a problem that could otherwise occur if an initiator process identifies resynchronized tokens and starts communicating with the responder before it receives a notification from the responder, since the responder's notification to the initiator could then be mistaken for a reply to the new communication and the initiator may try t
Hickson Andrew Ian
Maxwell Richard Scott
Raff Timothy Steven
Ware David
Lee Thomas
Yee & Associates P.C.
Zhen Li B.
LandOfFree
Interprocess communication mechanism does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Interprocess communication mechanism, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Interprocess communication mechanism will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3242095