Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Thread Communication

 
rob mcfarland
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 243
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
http://www.javaranch.com/ubb/Forum27/HTML/000119.html
THE ABOVE IS HAS THE CODE
 
Saji Pillai
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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);
}
}
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic