JavaParty

Remote Threads

Because the regular Java class java.lang.Thread is non-remote, it can only be allocated on the current node. To make allocation of activities on remote nodes more convenient, JavaParty declares a simple wrapper class for remote threads. The class jp.lang.RemoteThread itself is a remote class that allows a regular Java thread being controlled from a remote node. jp.lang.RemoteThread provides basically the same interface as java.lang.Tread.

Figure 1 shows the situation, where the application creates a new RemoteThread and passes a local Runnable object as argument. The remote thread is allocated in another virtual machine and the local argument is passes as argument to the same virtual machine as the remote thread is allocated in.

Figure 1. Using RemoteThread to create activities on remote nodes.

The invocation of the start() method is a remote method call to the RemoteThread object. When the remote thread is started, it spawns a newly allocated local Java thread that executes the run() method of the associated Runnable object. All methods for controlling the activity of the remote thread are remote invocations to the RemoteThread object, where they are forwarded to the local Java thread executing on behalf of the remote thread. The RemoteThread objects itself has no activity. This is indicated in the above diagram with missing color in the bar representing the RemoteThread object.

There is another possibility to create activities on far nodes, without using the RemoteThread class as shown in figure 2. Here the runnable object is declared remote and allocated on a far node. This remote runnable object is passes to the constructor of a local Java thread.

Figure 2. Using a local thread to create activities on remote nodes.

When starting the local Java thread, it immediately performs a remote method invocation to the run() method of its associated runnable object. The remote method is executed on the far node in a thread belonging to the communication subsystem. If the remote method run() returns, the locally created Java thread terminates.

With JavaParty's Transparent Threads, both approaches are functionally equivalent. The first one might consume slightly less resources, because there exist one activity less than in the second approach. The second one is slightly more convenient, because starting the activity is indistinguishable from regular Java.