Private Mutex

Problem

When writing a class with thread-safety in mind, the convenient "synchronized method" declaration comes to mind:

  public class Safe {
    //...
    public synchronized Object[] getValues() {...}
    public synchronized void putValue(Object o) {...}
    public synchronized boolean isEmpty() {...}
  }

  access synchronized return-type foo(args) {yadda}

  access return-type foo(args) {
    synchronized(this) {
      yadda
    }
  }

  //shared:
  Foo t;
  Safe s;
  int shared;

  //in thread 1:
  synchronized(s) {         //s guards shared
    synchronized(t) {
      while(!t.ready())
        try {t.wait();}
        catch(InterruptedException e) {}  //resume waiting
    }

    s.putValue(t);
    shared++;
  }

  //in thread 2:
  Object[] stuff=s.getValues();
  synchronized(t) {
    t.setValue(stuff.length);
    t.notify();
  }
  //We have to wait until t.notify() to synch on s:
  synchronized(s) {
    shared=stuff.length;
  }

An additional problem is demonstrated by the following (malicious) code:

  Safe s=your_safe;
  synchronized(s) {while(true);}

A third problem is the use of notify(). If the object on which your code synchronizes is visible outside your code (as it must be if you use synchronized methods and your class is to have clients), you can never guarantee that notify() will wake up a thread it makes any sense to wake up. A client may be wait()-ing on your object for its own reasons, and they are just as likely to get the notification as is the thread you had in mind. Of course, the simple solution is to use notifyAll(); however, then must you (and your clients!) not only add code to put all the other threads back to sleep, but you get the overhead of many threads waking up and sleeping again -- locking and unlocking monitors, blocking and unblocking each other, and generally context-switching as much as possible.

Solution

The solution, fortunately, is much simpler than any of the problems. Any object which needs to synchronize on itself for thread-safety should instead declare a private (final) member variable holding an object on which to synchronize, and then explicitly synchronize on it in the relevant functions:

  public class Independent {
    private final Object lock=new Object();

    public void wouldBeSynchronized() {
      synchronized(lock) {
        foo();
      }
    }
  }

  public class HandsOff {
    private static final Object classLock=new Object();

    public static void wouldBeSynchronized() {
      synchronized(classLock) {
        new HandsOff().bar();
      }
    }
  }

At risk of being controversial here, I will state that this pattern (although it is a useful pattern and one worth documenting in this Wiki), arises ONLY in Java, because it is nothing more than a way of working around a "wart" in the language. The "wart" was making each and every object be a mutex. Mutexes are a great idea, but Java was the first language (that I am aware of) to make each and every object a mutex, rather than creating a separate Mutex class and letting objects that needed synchronization hold Mutex instances. I would say that the experiment was a failure, and that designers of new languages would be wise to avoid having each object be a mutex. The motivation section of this pattern is only a minor reason why I believe the experiment was a failure, the main reason is the difficulty of implementing each-object-is-a-mutex without ridiculous overhead for most objects.

(Since it may be controversial, I will sign this one -- originally written by MichaelChermside. But feel free to revise it.)

And, further, at least in all JVM's I've worked with, the performance difference between the two approaches is huge... synchronizing on an object is generally about 10x slower than calling into a synchronized method, because the common case has been very highly optimized. --AdamBerger

Well, you could then wrap your synchronized methods in that object (i.e, private class), and delegate the appropriate method calls.

I'd note that the original problem could as easily be used as an argument to use only synchronized methods and not synchronized blocks as the opposite. That particular problem arises only when you mix the two idioms.

The more general problem of deadlocks is not prevented by either - if a synchronized method in A calls a synchronized method from object B, and in another thread a synchronized method in object B calls a synchronized method in object A, there is a potential for deadlock. The same can happen if you only use synchronized block and private mutexes, if code within a synchronized block in object A calls an object B method that has a synchronized block and vice versa. The real solution is to make your code simple enough and think about it hard enough to make sure that your synchronization never causes deadlocks. Using utility classes that are entirely thread safe - because they use a private mutex AND do not make any calls outside the class - can help.

Warren Dew

This page mirrored in JavaIdioms as of April 29, 2006