• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Doubt in K&B SCJP 5: topic Threads pg 728

 
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Original sentence(pg 728 line 2,3,4) is-

One is because we're calling wait() and notify() on this instance ,so we need to synchronize in order to avoid an IllegalThreadStateException

.

I think here Exception should be IllegalMonitorStateException.
 
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have the similar doubt regarding wait() and notify(). the scenario is somewhat like this " when one thread A is executing synchronized method and done with it, eventually it notifies with notifyall(). while the main thread which want to use the result of that thread A, then why we need to invoke wait() method on thread A instead the main thread is waiting ",

-i don't get it correctly, ,may its because when wait() is encountered by the instance of thread A it will release the lock., if so then thread A should release the all when it hits the notifyall()in sync code.

- please correct me if i am wrong somewhere.
- thank you
 
Ranch Hand
Posts: 893
Tomcat Server Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe that you're right when I read the following link

IllegalMonitorStateException
 
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I hope that I understand the issue correctly but here is the impression I get reading it.

The way to think of these things is that the issue of wait and notify is not simply about scheduling and the scheduling priorities ( it is NOT so much about WHO should be executing) but rather that there is some resource or structure that must be accessed exclusively, ONE thread at a time.

The idea of the synchronized method is that the API maintains/manages the "single thread access" to the method itself. Where a problem shows up is, once you get in there, if you find that you are missing some other resource that you need, wait() gives you a way to voluntarily release the locks and suspend the "owning" thread WHILE placing itself on a queue to await re-dispatching later WITH the LOCK already re-established. This helps to prevent threads from hanging on to locks for extended periods. So NOW we have a way that we can voluntarily say "let me give up the lock for now BUT put me back in later to re-try for my missing/unavailable resource.

SO now the JVM can dispatch another thread that may be waiting on the synchronized method. (the underlying idea here is that, somewhere in the application, whatever held the resource that was unavailable will relinquish it and call notify() or notifyAll(). This will tell the JVM "I am through with a protected resource so go dispatch a thread that may have been waiting on it".

The whole idea is that only ONE thread of execution has access to the resources at once, others have to wait, even if the priorities are upside down because the aim is to protect the integrity of the resource or structure. Now, if a higher priority thread is in wait,and a lower priority thread calls notifyAll(), I'd be willing to bet the higher priority thread will be dispatched pretty soon.
 
chintan ramavat
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
that was an excellent fundamental you've given Bob. thank you so much, i got the whole picture clear now.I'm very much appreciated bob, that was an awesome explanation, clearing many doubts.
 
Bob Ruth
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My pleasure. And if anyone can refine or correct it ... please do. Let's all learn more as we go.
 
Bob Ruth
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And, just as an afterthought, when you call wait() and are suspended you will eventually(thanks to someone's notify() call) be redispatched at the line following the wait with the synchronization lock for the method BACK IN PLACE.

BUT, depending on the logic that controls the resources, the rest of the resourcs might STILL not be ready yet, depending on how many resources are in question and how many threads are attempting to secure them. So, when you resume after a wait() it pays to re-check the resources you need.
 
She's brilliant. She can see what can be and is not limited to what is. And she knows this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic