Preserving thread identity during remote calls

Details Preserving thread identity during remote calls Preserving thread identity during remote calls

1999-02-09

2003-03-04

Courtenay, III, St. John (Department: 2126)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C709S229000

Reexamination Certificate

active

06529962

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates generally to methods of computing using remote calls between a local and a remote computer platform, and specifically to methods for preventing deadlock during such remote calls.
BACKGROUND OF THE INVENTION
Multitasking using a plurality of threads within a program is well known in the art. Multithread programming is described, for example, in “The Java Language Environment: A White Paper,” by James Gosling and Henry McGilton, published by Sun Microsystems, Inc., which is incorporated herein by reference. Use of more than one thread in a program allows multiple sequences of steps or states to be carried out by the program in parallel, by attaching a thread to each of the sequences. In the present patent application, the term thread refers to a sequence of steps carried out by the program. A thread has a thread identity as well as a priority.
In “Hooked on Java,” by van Hoff et al., published by Addison-Wesley Publishing Company, which is incorporated herein by reference, the authors explain in Chapter 5 that deadlock occurs when two or more threads are unable to continue because they are waiting on each other indefinitely. The authors outline some strategies for avoiding deadlock in threaded programs, including, where possible, avoiding creating more than one thread to execute methods. The authors further suggest trying to hold locks (explained in more detail below) created by threads for the shortest time possible.
When a thread obtains a lock for an object for the first time, an identity of the locking thread is recorded in the lock. On subsequent attempts by the thread to lock the same object, the system validates that this thread is the one recorded as “owning” the lock, and if so, allows the thread to proceed. Other threads attempting to use the locked object are locked out, and must wait until the original thread releases the lock. A deadlock occurs if a thread T
1
holds a lock L
1
and requests a lock L
2
, while a thread T
2
holds lock L
2
and requests lock L
1
. Deadlock of multiple threads on a single machine can generally be avoided by careful programming.
In modern network environments, a program (or program thread) running on a local computing machine will frequently invoke operation of a program on another, remote machine via a network, and will then receive the results back from the remote machine. Such invocation is referred to as a remote call. Depending on the nature program invoked, the remote machine may also respond with a callback to the local machine, i.e., with a remote call of its own. Remote Method Invocation (RMI) enables a programmer to create an object whose methods can be invoked on a remote computer. In “Using Java” by Joseph Weber, et al., published by Que Corporation, which is incorporated herein by reference, the authors describe in Chapter 40 steps involved in implementing a remote object for use in RMI. However, using RMI, or any other remote procedure call known in the art, breaks local-remote transparency and can lead to deadlocks, as described below.
Threaded programs running on a local and on a remote machine need to make remote calls between the machines. In so doing, each remote call leads to creation of a new thread on a respective target machine (either the local or the remote machine) . In the event that the target machine then makes a callback to the local machine, the original thread identity and/or priority is not preserved.
FIG. 1
is a schematic diagram illustrating a generation of deadlock caused by this process, as is known in the art. A thread T
1
, running on a source machine
10
, locks an object
16
and makes a remote call to a target machine
12
, thereby invoking a method
14
. The invoked method executes in a thread T
2
running on target machine
12
. During execution of this method, thread T
2
makes a remote callback to source machine
10
, which creates a new thread T
3
on machine
10
. If thread T
3
tries to perform a lock on object
16
, it will be unable to do so, and a deadlock will occur. Execution of a similar process in a single machine (without remote calls) will not cause any deadlocks, since for a single machine all locks are executed by the same thread. Thus, although it would be desirable for remote calls using RMI to be “transparent” to the programmer, i.e., to require no special attention to the fact that the desired method is invoked on a remote, rather than local, processor, in actuality the programmer must take particular care to avoid such deadlocks.
SUMMARY OF THE INVENTION
It is an object of some aspects of the present invention to provide methods for the preservation of local-remote transparency within a computer programming environment.
It is a further object of some aspects of the present invention to provide methods to prevent deadlock within a computer program operating on a local and a remote platform.
It is a yet further object of some aspects of the present invention to provide methods to preserve a thread identity within a computer program operating on a local and a remote platform.
In preferred embodiments of the present invention, when a first program thread running on a source machine makes a remote call to a target machine, the remote call includes an identification of the thread. When the target machine receives the remote call, it generates a second thread to carry out whatever method or methods are required by the call, and associates the identification with the second thread. If the target machine must then make a callback to the source machine, the identification is further associated with the callback. When the source machine receives the callback, it is able, using the identification associated therewith, to determine the identity of the first thread and, thus, to perform any method required by the callback using the first thread. As a result, the thread is allowed access to any objects that had previously been locked by the first thread on the source machine, and the possibility of deadlock due to the callback is avoided. It will be appreciated that any number of successive mutual callbacks between source and remote machines may be handled in this fashion.
In some preferred embodiments of the present invention, a remote transmission system on a source machine comprises a method relay manager (MRM) object and a thread supply object, which generates a thread responsive to a command from the MRM object. A target machine has a similar remote transmission system, comprising an MRM object and a thread supply object substantially similar to those on the source machine. All remote calls and corresponding callbacks between the machines are transmitted and received via the respective MRM objects, which use their respective thread supply objects to preserve an identity of a thread associated with a remote call from one of the machines to the other and then returned to the original machine.
By utilizing substantially similar systems in both the source and target machines, local-remote transparency is maintained, while the possibility of deadlocks occurring is eliminated by preserving the identity of the thread during the performance of remote calls and associated callbacks.
In some preferred embodiments of the present invention, the identity of the thread associated with the call and callbacks is preserved using one or more intermediate threads generated on one or both machines during a transmission of the call. The identities of the intermediate threads are modified, responsive to instructions from either the source or the target machine, so as to maintain consistency with thread naming conventions, such as conventions associated with Java language programming.
In some preferred embodiments of the present invention, an identity of a lock is used to record an owner of the lock associated with the thread when the remote call is made. The identity of the lock is transferred with the remote call, and the lock identity, rather than the identity of the thread, is used in initially locking objects and in order to gain access to alrea

Affiliated with

Also associated with

Rating

Preserving thread identity during remote calls does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Preserving thread identity during remote calls, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Preserving thread identity during remote calls will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3030522