JavaParty

Transparent Threads

Since JavaParty 1.07a

With transparent distributed threads, JavaParty provides unmodified Java thread semantics regarding synchronization and thread control in the distributed environment.

Transparent synchronization

Unlike in RMI and other RPC-style middle-ware platforms, synchronization semantics in JavaParty is the transparent extension from one virtual machine to the whole distributed environment.

Synchronization reentrance

In JavaParty, a distributed thread is allowed to re-enter an once acquired monitor no matter how many interleaving remote invocations are on the stack in between. This extends the Java thread semantic from one virtual machine to the whole distributed JavaParty environment.

With RMI and other RPC-style middle-ware platforms, re-entering a synchronization with interleaving remote method calls causes a dead-lock of the running application thread.

Details are explained in the section about Distributed Threads and the paper "Transparent Distributed Threads for Java".

Synchronized blocks

Besides synchronized methods, the Java language has so called synchronized blocks that are blocks of code synchronized on an arbitrary object. The object used for synchronization has not necessarily to be the one the surrounding method belongs to. In JavaParty, synchronized blocks are supported on arbitrary objects whether they are local or remote. This is possible because KaRMI supports "Remote Monitor Access (RMA)". JavaParty uses this feature to acquire the monitor of the object on the remote node, if the argument to the synchronized block statement is detected to be remote at runtime.

With a middle-ware platform like RMI or pure KaRMI blocks synchronized on remote objects are not possible, because the synchronization is acquired on the remote reference instead of the remote object itself.

Details are explained in the section about RMA and the paper "Transparent Distributed Threads for Java".

Transparent thread control

A thread of control spanning multiple virtual machines is managed by JavaParty as a whole. Control signals such as interrupts sent to a particular thread always reach the current head of control regardless whether it currently executes on a remote node or not.

With RMI, management of distributed threads is not possible, because interrupt signals only reach the local Java thread. If this thread is currently waiting in a remote method execution, the signal to get stuck at the local node waiting for the remote invocation to return. If the interruption is the only signal set to the thread this also causes a dead-lock.

Details are explained in the paper "Transparent Distributed Threads for Java".

Identification of transparent distributed threads

KaRMI provides distributed threads with an unique identifier. This thread ID is used internally, but may also be used by the application to identify a distributed thread of control. Regular Java has no means to identify a thread other than its corresponding thread object. In a distributed environment, the thread object is no longer appropriate for identification, because it is bound to the virtual machine where the distributed thread originated.

For details of thread IDs in KaRMI please consult the API documentation of the class ThreadInfo.

How to enable transparent threads in JavaParty

Distributed threads are enabled in JavaParty by default. Since there is some overhead regarding the latency of remote method invocations, you may want to disable the transparent distributed thread feature if your application only uses basic synchronization patterns.

There are two Java runtime properties that control the management of distributed threads:

uka.karmi.useDistributedThreads

If this property is set to true (which is the default value if the property is not set) you get complete synchronization transparence and distributed thread control. Disabling this feature, by setting the property value to false synchronization is no longer reentrant if remote method invocations lie in between two requests for the same monitor and thread control is restricted to the local Java thread.

uka.karmi.useThreadID

This property controls whether KaRMI is aware of distributed threads by assigning a unique identifier to each distributed thread. This identifier can be inspected by the application. The result is a unique number regardless on which node the inspection takes place. This feature is enabled by default. You can only disable this feature (setting the property value to false) by also disabling uka.karmi.useDistributedThreads.

Details are explained in the paper "Transparent Distributed Threads for Java".