Talk:Java Monitor

From APIDesign

@Synchronized does look good for some cases. However, it does not address (at least not without writing just as much code as doing it without annotations) a second class of monitor usage bugs that I find is very common: Using a single lock for multiple resources. It is very common to see a pattern such as:

public class Foo {
  private Bar bar;
  protected synchronized replaceBar() {
     bar = new Bar(xyz);
  }
  public synchronized Bar getBar() {
     return bar;
  }
  public synchronized void addPropertyChangeListener (PropertyChangeListener pcl) {
     ...
  }
  public synchronized void removePropertyChangeListener (PropertyChangeListener pcl) {
     ...
  }
 }

While this code is correct in that it will compile and run as the user expects,

1. There is much greater potential for deadlocks, and
2. An application with such code can have thread liveness problems

because the same monitor is being used to protect two unrelated resources from access collisions.

-Tim Boudreau

Right, this is the behavior. But it is not flaw of Java Monitor, it is a design decision of the inventor of monitor concept. The appropriate solution would be to put the separate concept into separate records/classes. So Java is using the monitor concept correctly (in this case), but one may treat this as another indication that monitors are not really suitable for OOP.

--JaroslavTulach 12:56, 31 January 2010 (UTC)

More flexibility by using a Lock

The Java developer should consider using Lock to improve flexibility over the Java monitor. I developed a library in 100% pure Java at https://sourceforge.net/projects/javamutex/ to support the java.util.concurrent.locks.Lock API. It uses the hidden Java monitor for very brief code paths to support the memory synchronization requirements of a Lock and to prevent interference from client code trying to synchronize on the Lock instance. My JavaMutex project on SourceForge.net is 100% pure Java, so it will run on any tiger-compliant Java Virtual Machine, and it's open source and freely redistributable.

I wrote it because I was uncomfortable relying the Sun Microsystems proprietary Lock support libraries that depend on the internal implementation of the Sun JVM (and also uses brief synchronized code paths).

Two cents worth. Your mileage may vary.

I looked at the API of your javamutex library and I found that by exposing less it could do more. I'd recommend use of factory methods rather than exposing subclassable classes and also clearly separating ClientAPI from ProviderAPI. ClarityOfTypes or at least ClarityOfAccessModifiers would not hurt either.

My two Kč. --JaroslavTulach 19:45, 22 April 2010 (UTC)

There are static factory methods available for creating the ReenterableLock and the ReenterableDualLock, as well as the ReenterableReadWriteLock that supports the Sun Microsystems ReadWriteLock interface. I separate the ClientAPI as public methods from the ProviderAPI as protected methods. Most of the protected methods are abstract to allow a provider to offer an alternative implementation through subclassing. The default implementation provides enough information for an alternative provider to add more functionality through subclassing. Please remember that this library has a very limited purpose of protecting threads and virtual tasks from stepping on each other. As it stands now, it is easy to start using it as is, and to add more stuff to it as needed. Thank you. Jeffrey D. Smith