my dog learned polymorphism*
The moose likes Threads and Synchronization and the fly likes thread overview. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "thread overview." Watch "thread overview." New topic
Author

thread overview.

Yuan Ye
Ranch Hand

Joined: Mar 05, 2003
Posts: 172
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
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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

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.


"I'm not back." - Bill Harding, Twister
Yuan Ye
Ranch Hand

Joined: Mar 05, 2003
Posts: 172
Jim,
You are the best. Thank you very much! You answered my questions even though I didn't express well.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: thread overview.
 
Similar Threads
Thread states, notify, notifyAll, wait
unlock method
SCJD B&S locking
[ NO PASS!!! ] - What happen???
NX: My Locking Mechanism