• 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

Synchronized methods and blocks

 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to ensure I have unstood correctly what I have read.
A synchronized block or method, with no wait/notify calls being employed, will allow only one thread to enter it (get the lock so to speak) at a time.
Even if we use wait/notify, a waiting thread will only be able to execute within the synchronized block or method when the notifying thread has left, so again only one thread may be active within the synchronized block at one time.
But now comes the case that I am unclear on. if you have two or more waiting threads in a synchronized block or method, and another thread performs a notifyAll, I supposed the waiting threads (as with the notify case) wait until the thread performing the notifyAll exits the synchronized block. But what then? As I have read, all of the waiting threads become 'runnable' which mean that they may be active within the synchronized block at the same time.
I don't have a problem with this - in fact in a writer with mutiple readers situation it makes complete sense to allow the readers to all act concurrently. I just want to make sure that I am correct in the following understand:
By using the wait/notifyAll mechanism, it is possible for mutilple threads to be active within a synchronized block or method.
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sean,


But what then? As I have read, all of the waiting threads become 'runnable' which mean that they may be active within the synchronized block at the same time.


The waiting threads will not be active/run within the synchronized block at the same time. When the waiting threads become Runnable, it is simply sitting on the Runnable pool, waiting to be picked by the Thread scheduler to run. Which one will be picked to run first? No guarantee. So, the first of those threads that get picked by Thread scheduler to run first will re-obtain the lock, and the other threads (which are also synchronized with the same lock) will have to wait until this thread releases the lock before each of them can be back running in the synchronized block.
Does it make sense?
[ February 17, 2004: Message edited by: David Hadiprijanto ]
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The key to remember in this case is that no two threads will EVER be executing within the same synchronized block at the same time. If they could, what would be the point of having a synchronized block?
 
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also,
to add- the threads have a priority set. so they will run according to which one has highest priority. But if 2 threads have same priority then what happens?
 
Sean Walker
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for responding David Hadiprijanto.
I'm still in a fog on this. From what you have said, I can't see what the difference is betwen a notify call and a notifyAll call.
Please distinguish between the two calls, especially in the situation I have described above - unless, of course, the situation I described assumes something that is not correct.
Thank you.
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Shivan,
If two threads have the same priority then the JVM will choose one (you can't know wich one).
 
Ranch Hand
Posts: 456
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello everyone,
I entered the saloon in order to post a question which happened to be that close to Sean's question, that I'll post mine in this thread.
I have a problem in understanding why I should ever need notifyAll().
If an object OneObject has to have aquired a lock on an OtherObject it wants to wait() for, and if - obviously - only one object can hold this lock at any given point of time, doesn't this mean that at any given point only one thread can have called the OtherObject.wait()?
In my understanding, all other threads 'planning' to call OtherObject.wait() have to do this from inbetween a synchronized(OtherObject) block.
And as you all just discussed, only one thread A will be able to enter the synchronized block (and execute the wait()), all other threads B,C,... will wait outside until A has been notified and continued the code in the synchronized block.
I'm pretty sure that I got something wrong... So, where's the point? How can different threads call wait() on the same object?
Thx,
Jan
 
David Hadiprijanto
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sean,


Please distinguish between the two calls, especially in the situation I have described above - unless, of course, the situation I described assumes something that is not correct.


notify() will cause only one object in the waiting list of the corresponding object to be notified and be put back on Runnable state. Which one? No guarantee.
notifyAll() will cause all objects in the waiting list of the corresponding object to be notified and be put back on Runnable state.
So, in your situation above (writer and reader):
1. If you use notify() on the writer, only one of the reader threads (JVM decide which one) will be made Runnable. Obviously, this is not desired in this situation.
2. If you use notifyAll() on the writer, all the reader threads will be made Runnable - and all of them will then fight for the lock again so only one thread will be running in the synchronized block.
So, which one to use? I think if you are dealing with multiple objects waiting on the same object, usually you want to use notifyAll().
I hope this helps you to make the distinction between notify() and notifyAll(). They are quite simple, I think, really .
[ February 19, 2004: Message edited by: David Hadiprijanto ]
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sean Walker:

But what then? As I have read, all of the waiting threads become 'runnable' which mean that they may be active within the synchronized block at the same time.

 
Dave Wolf
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sean Walker:

But what then? As I have read, all of the waiting threads become 'runnable' which mean that they may be active within the synchronized block at the same time.


Sorry for my previous post. I'll give it another try here.
It's my understanding that you are correct when you say the threads become runnable. When a thread becomes runnable though, it becomes 'eligible' to move to the 'running' state, or 'active' as you put it. If a thread is in a sleep/wait/block state, it has to become runnable, then the thread schedular has to choose it from the group of runnable threads before it actually does anything.
Hope this helps.
-Dave-
 
Dave Wolf
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jan Groth:

If an object OneObject has to have aquired a lock on an OtherObject it wants to wait() for, and if - obviously - only one object can hold this lock at any given point of time, doesn't this mean that at any given point only one thread can have called the OtherObject.wait()?



From the Java 1.4.2 API (wait() in 'Object')...
Java 1.4.2 API


The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method. The thread then waits until it can re-obtain ownership of the monitor and resumes execution.


It's probably safe to substitute 'lock' for 'monitor' in the above quote. Note that its states that the thread that owns the lock in order to call the wait() method, then gives it (the lock) up while it is waiting. This allows other threads to then call wait() on that same object.
Hope this helps to answer your question.
-Dave-
 
Jan Groth
Ranch Hand
Posts: 456
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dave,
this makes everything perfectly clear.
Thanks for helping,
- Jan -
 
reply
    Bookmark Topic Watch Topic
  • New Topic