thread overview.

[Yuan Ye]

Here is my understanding of wait(), notifyall() and synchronized block. I asked some question that I am not sure. Please give me your comment.
The code segments:
seg1:
synchrnized(a) {
wait();
}
seg2:
synchronized(a) {
notifyall;
}
supposing we have 4 threads t1--t4, initially t1 and t2 threads are trying to access seg1 simutanuously. Supposing t1 get into seg1, t2 will wait(not exactly wait) outside and continuous trying. Then t1 hits wait(); go to wait state. Now t2 go into seg1 and also wait(). Then thread t3 executes seg2, since t1 and t2 are waiting, t3 will obtain the lock and call notifyall(), both t1 and t2 are awake. But meanwhile a new thread t4 is also trying to access seg1, so is it true that t1 and t2 have high priority than t4 since they are already in the waiting state, or they all have same priority?
Now supposing t1 is selected to go into seg1, after t1 exits. Does t2 need to be notified again to be executable? Or t2 just compete with any thread trying to go the synchronized block?

[Jim Yingst]

First off, the code you showed will throw IllegalMonitorStateException because wait() and notifyAll() are being called from code that doesn't hold the correct monitor lock. You sync on monitor "a", good, but then you call wait() using the implicit "this" reference. (I.e. "wait()" is equivalet to "this.wait()".) Unless (a == this), these are two different objects, and you haven't acquired a sync lock on the object you're invoking wait() with, so you'll throw an IllegalMonitorStateException. Same problem for the notifyAll() call.
All right, lets replace the code with

seg1:
synchrnized(a) {
    a.wait();
}
seg2:
synchronized(a) {
    a.notifyAll();
}

Supposing t1 get into seg1, t2 will wait(not exactly wait) outside and continuous trying.
Right. Instead of "wait", say t2 will block until it can acquire the sync lock. "Wait" implies the wait() method, which is not what t2 is doing (yet).
But meanwhile a new thread t4 is also trying to access seg1, so is it true that t1 and t2 have high priority than t4 since they are already in the waiting state, or they all have same priority?
They should all have the same priority. Though some implementations may effecitively give t1 and t2 higher priority, or t4 higher - priorities are not defined in any precise terms, and different implementations can do different things here if they wish. But in principle, t1, t2, and t4 have equal chances at this point.
Now supposing t1 is selected to go into seg1, after t1 exits.
Uh... what?
Does t2 need to be notified again to be executable? Or t2 just compete with any thread trying to go the synchronized block?
t2 entered wait() once, then it received a notifyAll() - it will not require any additional notification unless it enters a wait() again. at this point it's merely blocking (not waiting) until it can acquire a sync lock on monitor a.
Incidentally, for any actual working code, you would want to put the call to wiat() inside a loop of some kind which checks to make sure that the notifyAll() has not already been called. Typically there's some state variable in the system that you'd check; you're essentially wait()ing until some condition is met. (And elsewhere, the code that actually fulfills the condition you're waiting for is the code that calls notifyAll() so you can stop wait()ing.) So you'd want the wait() code to make sure the condition wasn't already fulfilled, because if it was, the notifyAll() call has already been sent, and if you wait() now you'll wait() forever. See Effective Java Item 50: "Never invoke wait() outside a loop" for more info.

[Yuan Ye]

Jim,
You are the best. Thank you very much! You answered my questions even though I didn't express well.