Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Wait And Notify concept

 
Animesh Shrivastava
Ranch Hand
Posts: 298
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey All,
I am having some problem in using Wait and Notify, Please let me know where i am going wrong. I am not able to get the concept of Wait and Notify properly.

here is the program:




When i run the program above, i guess it goes into deadlock state. i would like to know, why is this happening?

Thanks
 
Vipin Das
Ranch Hand
Posts: 47
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Why do you think it has reached a dead lock? What are your reasons?
 
Animesh Shrivastava
Ranch Hand
Posts: 298
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, i posted the same question in thread and Synchronization question forum. I got the reply as here

Actually thru this code even i didnt know what my aim was. just playing arounf Notify and Wait. I am not very much able to understand the concept of Wait and Notify.
I just thought that it must be deadlock as the program got stuck. But after finding the reply i found myself wrong.
 
Mike Gershman
Ranch Hand
Posts: 1272
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
notify() does not affect future wait() calls. You notify before wait logic is a guaranteed deadlock.

One version of events follows:
Thread1 gets the lock, prints the message, issues a useless notify, releases the lock, gets the lock again, and waits (this releases the lock).
Thread2 gets the lock, prints the message, issues a notify, and releases the lock.
Thread1 gets the lock again, releases the lock, and finishes.
Thread2 gets the lock and waits forever because Thread1 already issued its notify.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Animesh,

here is an example from the K&B book:



Whereever you have this combination synchronized(A)/synchronized(B) and synchronized(B)/synchronized(A) (see the opposite order, waiting on each other) you are going for deadlock.

Regards,
Darya
[ February 18, 2005: Message edited by: Darya Akbari ]
 
Vipin Das
Ranch Hand
Posts: 47
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
when your program runs 2 thread objects will be created, extThread1 and

extThread2.Then first thread comes give a notify() and come to the wait() and starts waiting on the extThread1 object. The second thread pass through the above steps and start waiting in the extThread2 object.
The notify of the first thread will be effective on the second thread only if they notify and wait on a common object. Here they are waiting and notify on themselves. Therefore there wont be anyo effect.
Even if you correct that problem, the second thread will wait for ever since no thread will be there to notify it. Now modify the program yourself.
 
Animesh Shrivastava
Ranch Hand
Posts: 298
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From Mike:
Thread1 gets the lock, prints the message, issues a useless notify, releases the lock, gets the lock again, and waits (this releases the lock).
Thread2 gets the lock, prints the message, issues a notify, and releases the lock.
Thread1 gets the lock again, releases the lock, and finishes.
Thread2 gets the lock and waits forever because Thread1 already issued its notify.


I have few question regarding ur mentioned points:

[LIST]
1) In the first point u have said at the end the Thread 1 gets the lock again, and waits()(this releases the lock)
how is this possible?
2) I came to know that there are two thread objects created, these threads are not sharing a common object. They both are running on different objects. So ur fourth point looks non existing. Am i right?

I guess Vipin's answer to the solution seems to be on the right track. Anyways, more feedbacks on these would be really effective

Waiting for ur replies

thanks
 
ramaseshan T
Ranch Hand
Posts: 30
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. These are two seperate threads and have their own memory space
2. There is no question of deadlock here because each thread is not locked upon each other. Each thread after issuing notify () calls, starts waiting infinitely..Note, they are not contending for each other's object..Just waiting to get notification from some other thread. But there is no thread to notify..

Please correct me if I am wrong.
 
Animesh Shrivastava
Ranch Hand
Posts: 298
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, does this mean that if wait() is invoked, there has to be a notify for it or else the code gets stuck.
Am i right?
Anyways, i agree with whatever u say, i guess thats the main problem in my code.

Thanks
 
Jay Pawar
Ranch Hand
Posts: 411
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Animesh Shrivastava:
So, does this mean that if wait() is invoked, there has to be a notify for it or else the code gets stuck.
Am i right?


Yes correct, there has to be notify or notifyAll method call for this object.
 
Mike Gershman
Ranch Hand
Posts: 1272
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the first point u have said at the end the Thread 1 gets the lock again, and waits()(this releases the lock)
how is this possible?

Look up Object.wait() in the API doc. wait() releases the lock it is called on.
I came to know that there are two thread objects created, these threads are not sharing a common object. They both are running on different objects. So ur fourth point looks non existing. Am i right?

You are right that there are separate locks for each thread. Sorry, I missed that. However, notify before wait will not work.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic