具有同步方法和同步语句的对象如何分别类似于监视器和条件关键区域？

Question

From Programming Language Pragmatics, by Scott

Java objects that use only synchronized methods (no locks or synchronized statements) closely resemble Mesa monitors in which there is a limit of one condition variable per monitor (and in fact objects with synchronized statements are sometimes referred to as monitors in Java).

Why are Java objects that use only synchronized methods closely resemble Mesa monitors in which there is a limit of one condition variable per monitor?

Is it correct that there is no condition variable in "Java objects that use only synchronized methods"? So how can it resembles a monitor with one condition variable?

By the same token, a synchronized statement in Java that begins with a wait in a loop resembles a CCR in which the retesting of conditions has been made explicit . Because notify also is explicit, a Java implementation need not reevaluate conditions (or wake up threads that do so explicitly) on every exit from a critical section—only those in which a notify occurs.

Why does a synchronized statement in Java that begins with a wait in a loop resembles a CCR (conditional critical region) in which the retesting of conditions has been made explicit?

What does it mean by "Because notify also is explicit, a Java implementation need not reevaluate conditions (or wake up threads that do so explicitly) on every exit from a critical section—only those in which a notify occurs"?

Thanks.

Answer 1

All this is saying is that in Java intrinsic locks have the condition baked into them. Contrast this with ReentrantLock where you can explicitly have separate conditions with the same lock.

If you have separate conditions then you can signal a given condition and know only threads in the wait set for that condition will receive it. If you don't have separate condition objects then upon being notified you have to check to see if that condition applies to you.

An example of this would be a fixed size blocking queue. If you look at ArrayBlockingQueue, it's implemented with ReentrantLock so that putting and taking use separate condition objects. If this was implemented using the intrinsic lock on the Queue object it would have to use notifyAll to wake up waiting threads, which would then have to test the condition they woke up from waiting on to find out if it was relevant to them.

Here is a blocking queue written using an intrinsic lock. If notify was used then a single thread would be woken by the scheduler and (since threads could be waiting to put or waiting to take) it might or might not be one that the notify was relevant to. To make sure the notification doesn't get lost all the waiting threads get notified:

public class Queue<T>{

    private final int maxSize;
    private List<T> list = new ArrayList<>();
    public Queue(int maxSize) {
        this.maxSize = maxSize;
    }

    public synchronized T take() throws InterruptedException {
        while (list.size() == 0) {
            wait();
         }
         notifyAll();
         return list.remove(0)(
    }

    public synchronized void put(T entry) throws InterruptedException {
        while (list.size() == maxSize) {
            wait();
        }
        list.add(entry);
        notifyAll();
    }
}