views:

125

answers:

2

Hello Experts,

I would appreciate your help in understand a "Concurrency Example" from: http://forums.sun.com/thread.jspa?threadID=735386

Qute Start:

public synchronized void enqueue(T obj) {
    // do addition to internal list and then...
    this.notify();
}

public synchronized T dequeue() {
    while (this.size()==0) {
        this.wait(); 
    }
    return // something from the queue
}

Quote End:

My Question is: Why is this code valid?

=> When I synchronize a method like "public synchronized" => then I synchronize on the "Instance of the Object ==> this". However in the example above:

  1. Calling "dequeue" I will get the "lock/monitor" on this

  2. Now I am in the dequeue method. As the list is zero, the calling thread will be "waited"

  3. From my understanding I have now a deadlock situation, as I will have no chance of ever enquing an object (from an nother thread), as the "dequeue" method is not yet finised and the dequeue "method" holds the lock on this: So I will never ever get the possibility to call "enequeue" as I will not get the "this" lock.

Backround: I have exactly the same problem: I have some kind of connection pool (List of Connections) and need to block if all connections are checked. What is the correct way to synchronize the List to block, if size exceeds a limit or is zero?

Thank you very much

Jens

+6  A: 

See: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#wait()

"The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method. The thread then waits until it can re-obtain ownership of the monitor and resumes execution."

So no, there is no deadlock. When wait() is called, the monitor held by the thread is released, allowing enqueue (and other operations that are synchronized on this object) to be called on another thread. When the thread is notified, it will try to obtain the monitor again before continuing.

Chris Henry
+1  A: 

There is no deadlock cause calling wait will give up the lock. you might check this out: http://stackoverflow.com/questions/2779484/why-wait-should-always-be-in-synchronized-block

daedlus
Thanks for your help, the link is very insightfull!
jens