• Post Reply Bookmark Topic Watch Topic
  • New Topic

What's wrong with the code?  RSS feed

 
Shubham Semwal
Ranch Hand
Posts: 176
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tried to use thread interaction but even if i comment notifyAll() it's still working as expected. :O

 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What, exactly, did you expect to happen, and what is actually happening?
 
Shubham Semwal
Ranch Hand
Posts: 176
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf Dittmer wrote:What, exactly, did you expect to happen, and what is actually happening?



i thought that the Threads would wait until they are notified. But the code is working even without notifyAll(). I'm unable to find out the reason for this behaviour.
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't say I fully understand what this code is supposed to show, but here are some observations:

- Only in very exceptional circumstances (which do not apply here) should you extend Thread: http://www.coderanch.com/how-to/java/ExtendingThreadVsImplementingRunnable

- Reading variables across threads (like the code does with the "a" boolean) is problematic. If you really need to do that, you need to read up on "volatile" and its caveats.

- Note that you're invoking the wait method on a thread that very likely has not been started at that point. Think about what that means.
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The thread exits after the notifyAll comment, that's causing your waits to wake up.

Place a long sleep followed by a System.out.println ("hello world"); at the // notifyAll comment and you should see the children die after the "hello world", add the notifyAll back in and you should see the children die first then the hello world.
 
Shubham Semwal
Ranch Hand
Posts: 176
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So if Thread A is waiting for Thread B and Thread B dies(after completing the task) will Thread A resume automatically ??
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Really wait should be always be in a loop (good practice), when you exit the loop you should test for a variable/state (set prior to notify / should be volatile write/read) and exit the loop as required.

Wait is allowed to exit spuriously , i.e. it could just do it (long explanation / spurious wake up would be expected to be rare) , even without the thread exit in this case.

I'd strongly advise you to read this ...

java wait documentation
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shubham Semwal wrote:So if Thread A is waiting for Thread B and Thread B dies(after completing the task) will Thread A resume automatically ??


Yes, part of the end of a Thread's life is a notifyAll(). This is used as part of the join() mechanism, and is an implementation detail so you can't rely on it but it can hurt you. It means you can't reliably use a Thread object for a lock monitor. You should use something else. I like to use the Object whose data is being protected by synchronization, or if the data is primitive than I will create an Object specific for use as a lock (Object lock = new Object();). Or, of course, you could use the Lock/Condition mechanisms available in java.util.concurrent.
 
Shubham Semwal
Ranch Hand
Posts: 176
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all
 
Abhineet Kapil
Ranch Hand
Posts: 52
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Chris/Ulf,

If we are checking the boolean status inside synchronized block, do we still need to use the volatile variable ?

I would believe synchronized should be enough.

Your suggestions ?
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this case synchronized is enough as all your writes and reads of a are in synchronized blocks with the same lock (well except boolean a=false; but other threads seeing initially at least false is guaranteed by the JMM anyway, not an issue)

So you don't need volatile in this instance as written.
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve Luke wrote:It means you can't reliably use a Thread object for a lock monitor. You should use something else.


I have never used a Thread object as a monitor, so I never thought about this case. It was a new thing I learned. Thank you.

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!