File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Thread Communication Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Thread Communication" Watch "Thread Communication" New topic
Author

Thread Communication

rob mcfarland
Greenhorn

Joined: Oct 04, 2000
Posts: 11
Several recent postings from people who've taken the new exam have emphasised how important it is to have a solid understanding of Threads and their sychronization. I thought I had a fairly solid understanding until I managed to write some code where a Thread is removed from a wait state on a particular object without another Thread having called notify() or notifyAll() on that object. My whole basis of Thread understanding is threatening to crumble around me and I desperately need some guidance. I originally posted this question in the Threads forum yesterday and although have had one reply (thanks for that) it still hasn't really cleared it up. Unfortunately the code looks fairly daunting, just because there's a fair bit of it, but what its doing really is very straightforward. I'm sure I'm making the sort of mistake a recently born infant could spot but I'm suffering from code blindness. If anyone feels brave enough to tackle it, its posted under the same title 'Thread Communication'. All I can offer in the way of an incentive is potentially a marriage proposal (don't worry, you don't have to say yes). If thats not enough, just think of the sense of mental superiority.
Yours hopefully,
Rob.
Vivek Nambiar
Ranch Hand

Joined: Sep 25, 2000
Posts: 63
http://www.javaranch.com/maha/Discussions/Threads/threads.html
COULD U CHECK THIS SITE...IT HAS INTERESTING DISCUSSIONS ON THREADS...HOPE IT CLEARS ALL UR DOUBTS!
rob mcfarland
Greenhorn

Joined: Oct 04, 2000
Posts: 11
Vivek,
Yes, I've studied all the discussion threads on Maha's site and unfortunately none of them really cover this. My understanding is that when a thread enters a wait state (by calling wait()) within a synchronized code block on a specific object (synchronized(obj)) then the only way it can come out of this wait state (apart from another thread calling interrupt()) is for another thread to call obj.notify() or obj.notifyAll(). My example contains two threads both waiting on the same resource. obj.notifyAll() is called and only one thread should get the lock and continue. The other should continue waiting until the next call to obj.notifyAll(). That doesn't seem to be happening. The second thread comes out of its wait state when it feels like it. Any help would really be appreciated.
Cheers,
Rob.
Vivek Nambiar
Ranch Hand

Joined: Sep 25, 2000
Posts: 63
I am sorry did not check ur code. Shall get back to u after properly studying it.
Thanks for the reply anyway!
rgds,
vivek
mohit joshi
Ranch Hand

Joined: Sep 23, 2000
Posts: 243
There is no post by you on threads On this forum in last few days. Why dont you post your code here. I tried searching for it but couldnot find it.
Vivek Nambiar
Ranch Hand

Joined: Sep 25, 2000
Posts: 63
http://www.javaranch.com/ubb/Forum27/HTML/000119.html
THE ABOVE IS HAS THE CODE
Saji Pillai
Greenhorn

Joined: Oct 13, 2000
Posts: 1
My understanding is that when you call notifyAll(), all the objects waiting in the pool to be notified are moved out of waiting state. But only one of them can acquire a lock on the object. The other threads which are now waiting for the lock (not for notification) may acquire the object lock whenever it becomes available. You could modify your code to get the desired effect by using notify().
BTW, I haven't gone thru your code
Based my explanation on the situation you described.
Larry LeFever
Greenhorn

Joined: Jun 13, 2000
Posts: 18
See "Taming Java Threads", by Holub. He demonstrates the use of the concept of a "spin lock". It's simply a matter of testing a condition-variable in a while-loop, rather than testing it only in a simple if-statement.
The need for this arises from the fact (according the book in question) that "wait()" cannot be relied upon to have been implemented "atomically". Consequently, thread A might be notified first but get the lock second (relative to some other thread B, say). This allows thread B to change the condition in question to the opposite of what thread A assumes it will be once it's notified. In such cases (without a "spin lock"), the thread (i.e., thread A), once notified, will run code that assumes a certain condition that's false is true, and that, as they used to say, is a "Bad Thing".

// Check if its empty and wait if it is
if(tray.isEmpty())
{
System.out.println(name + "Oh no, its empty. Better wait then...");

try
{
tray.wait();
System.out.println(name + "...finished waiting");
}
catch(InterruptedException e)
{
System.out.println(e);
}
}

Sun-Certified Java Programmer
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread Communication