• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Notify and wait code problem

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



Here It is showing ouptut:-
i=0in t1
i=1in t4
Thread-0is running
Thread-1is notifying
notified

but why after printing "notified" it doesn't loose lock to thread "t1 run() method " and continue with the code after wait() in t1 . i.e it should print "Thread-0is waken up" after printing "notified".
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is because you have used synchronized block for each thread.
No other thread will wake up and start executing unless the current thread has done execution in its synchronized block.

Please correct me If I am Wrong.
 
Aditya Soni
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
so you mean to say calling notify() method won't release lock.?

correct me if am wrong!
 
Saloon Keeper
Posts: 12154
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Calling notify() will wake up one thread that has called wait() on the same object you called notify() on.

Sadly, you didn't call wait() and notify() on the same object. Hint: in this case the type of your lock object is Runnable, not NotifyAndWaitExample2.

A few other remarks:

You should always call wait() inside a loop that checks a condition. wait() is allowed to return without any thread having called notify() or notifyAll(), so you need to communicate between the threads using a condition.

Don't use synchronized in the method declaration, and don't synchronize on this. 9 out of 10 times, your lock should be owned by the object you want to synchronize, and it shouldn't be available to the outside world. That means you should do something like this:

However, since Java released the concurrency framework, you wouldn't use synchronized blocks anymore, and prefer Lock instead:
 
Aditya Soni
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for replying,

So there are two more questions arise on mind after reading your answer i.e.

1) Why we can't we use "this" instead of private "lock" reference ??
2) And is calling notify will release the lock also? so as another thread will accquire the lock and continue its work?


hope you
 
VarunS Singh
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have a look. Here what the problem is when notify is called in the synchronized method of thread t4, dont you think you will be needing to rerun the t1 thread again.
Thats what I did here, add t1.run() in your code and see if it helps

 
Stephan van Hulst
Saloon Keeper
Posts: 12154
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, that is downright wrong. That will just cause the second thread to run the code that was initially given to the first thread to run, making it run twice, and deadlocking the program because both threads will be stuck waiting.
 
Ranch Hand
Posts: 86
18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Synchronizing on this can be useful (see e.g. Collections#synchronizedXXX), but exposing the used lock object (which is done by locking on this) provides a way to block the method(s) in a malicious way (on purpose or accidentally), i.e. the following code would block the run method forever once it acquires the lock.


Notify will not release the lock, the notified thread(s) have to wait until the caller of the #notify method releases the objects monitor.
 
Stephan van Hulst
Saloon Keeper
Posts: 12154
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Aditya Soni wrote:1) Why we can't we use "this" instead of private "lock" reference ??


Because this refers to different objects. For the first thread, this refers to the Runnable that you passed to the first thread, and for the second thread this refers to the Runnable that you passed to the second thread.

That means the first thread is waiting on a different object that the object that the second thread notified.

Explain to us what object you wanted to wait on when you called wait() and notify().

2) And is calling notify will release the lock also? so as another thread will accquire the lock and continue its work?


There is no one lock. You're using two locks.
 
author
Posts: 23879
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:
There is no one lock. You're using two locks.



As an aside, another issue is that the notification is done in the blind. There is no state, and hence, no checking if waiting is even needed.

This means, even if the OP fixed the issues, and use a single shared lock... there is still a race condition, where the t4 thread gets the lock first, and sends the notification. This notification would be lost, and since there is no state, there is no way that the t1 thread would even know that the t4 thread already executed, and simply waits for a notification (that has already been sent and discarded).

Henry
 
Are you here to take over the surface world? Because this tiny ad will stop you!
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic