JavaParty

Synchronization

Since JavaParty 1.07a

In JavaParty the syntax for synchronization is the same as in the regular Java language: Methods of remote objects can have the synchronized modifier, and remote objects can be passed as argument to a synchronized block.

public remote class R {
   public synchronized void foo() {
      // A synchronized remote method
   }
}

public void foo() {
   R remoteObject = ...;

   synchronized (remoteObject) {
      // A block synchronized 
      // on a remote object
   }
}

Thanks to the Transparent Threads feature of JavaParty, you can use both forms of synchronization as you are used to in regular non-distributed Java. Since writing parallel programs and using synchronization right is a difficult task, it is recommended to read the section about synchronizing threads in the Java tutorial and the section about threads and locks in the Java language specification.

But even if synchronization is transparent in JavaParty, finding out why something goes wrong in a parallel distributed program might be more difficult than in a parallel non-distributed one.

Tips and Tricks using Synchronisation

If you consider the following rules of thumbs, you should be able to avoid most pitfalls regarding Java synchronization:

Only have one synchronization monitor acquired at a time.

This prevents most dead-locks, because you do not need to care about the order in witch you acquire the synchronization.

Acquire synchronization monitors in a unique order.

This prevents dead-lock due to concurrent requests for multiple synchronization monitors.

Do not wait for signals holding more than one synchronization monitor.

When waiting only the innermost synchronization monitor is released. This may cause a dead-lock, if the thread from which you expect the signal also tries to acquire both synchronization monitors. Here does not help even a global unique order for synchronization requests.

Prefer synchronized methods over synchronized blocks.

This keeps all synchronization related stuff together in the class you synchronize on. This helps you keep a better overview of the locks a particular thread acquires.

Use synchronized static methods only in remote classes.

Since local classes are loaded on each node separately, their synchronization monitor is a different one on each node. This rule avoids erroneously acquiring the synchronizing concurrently on the same class multiple times on different nodes.