synchronized(this) and observers notifications

Question

This is related, but definitely not identical, to this famous SO question:

Very often I've got an "observable subject" that likes to notify its observers when it is modified. The notification is basically making "alien method" calls (as they're called in Effective Java etc.) I may have something like this:

public void updateData(params) {
    synchronized (this) {
        // do some computation here
    }
    notifyObservers(); // Never, EVER, call an alien method with a lock held (see Effective Java)
}

public synchronized Result getResult() {
   ...
}

Should I be avoiding the synchronized(this) and hence also remove the synchronized from the getResult() method?

Is this the following that people advising against synchronized(this) are recommending:

private final Object lock = new Object(); // shiny lock

public void updateDate(params) {
    synchronized( lock ) {
       ...
    }
    notifyObservers();
}

public Result getResult() {
    synchronized( lock ) {
        return Result;
    }
}

As a bonus question that doesn't warrant it's own SO question: if the latter is recommended, what do people who advise against using synchronized(this) think about the fact that methods in Java can be declared as "synchronized"?

Note that if using a private lock is preferred in this observers/notification case, I've got absolutely zero problem switching my code to the "private lock" idiom :) — SyntaxT3rr0r, Apr 13 '11 at 12:34

score 1 · Answer 1 · answered Jan 11 '12 at 18:15

If you are concerned about exposing your lock, you don't want to make it a part of your API or you have a finer-grained locking policy and one lock isn't enough, you could use use a private lock as you described.

Note however that there is another, much more flexible alternative: ReentrantLock. One of the disadvantages of intrinsic locks not mentioned in the question which you referred to is that they only support uninterruptible lock acquisition. On the other hand, ReentrantLock provides methods for checking lock status, interruptible acquisition and acquisition with a timeout.

Interruptible acquisition is particularly useful when writing cancelable tasks since it follows the general prescription for blocking methods to throw InterruptedException to signal thread interruption in a blocking operation. The cancelation mechanism based on interruption is followed by Executors from java.util.concurrent.

synchronized(this) and observers notifications

1 Answers1