• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Thread synchronization question: queued or not?

 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!
I have a synchronization question:
I have the following code:
int waiting = 0;
object obj = new Object();
public void foo()
{
waiting++;
synchronized (obj)
{
waiting--;
...
}
}
Of course that when many threads try to enter that method, only the first will succeed and that other will wait at the synchronized block.
My question is that: Suppose threads A, B, C, D, E arrive at this order and thread A captures the obj Object's monitor at the synchronized block. Meanwhile thread B is waiting, and so is C, D, E (B came first, and so on).
When A releases the monitor at the end of the synchronized block - to the waiting threads enter it in a queue manner (i.e. B, then when B is done C, and so on) - or is it random?
I have tested that over and over again, because I thought that the order is random, but in every time I saw (with debug prints) that is had the behaviour of a queue. There wasn't a single time it went otherwise.
Since it is important for me to have it as a queue, I really need to know whether that is the defined behaviour or maybe that was just incident.
Can anyone help me?
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think the java specification declares which order the threads will be restarted but the JVM may have implemented that as a queue. So you propably shouldn't rely on it being a queue but I could be wrong. Just remember that a thread of higher priority will always start first.
 
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When calling notify(), it's left up to the JVM to implement which thread is woke up, but this is in regards to threads that have been put into wait mode. I think I'd go with what Jeremy said and not count on the behavior you are getting for all platforms.
From the API


If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation.


Jason
[This message has been edited by jason adam (edited January 02, 2002).]
 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If U called notify, we cannot ensure which thread will capture it. Even when U call notifyAll, there is no prove that the first waiting thread will grasp the lock.
 
author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


"Just remember that a thread of higher priority will always start first."


This is not true. Threads with higher priority might execute first, but you can't rely on it, even on the same system. For why this is so and how to programmically choose a thread to run when calling notify or notifyAll, see my article here.
The original question is interesting though. My article specifically deals with wait, notify, and notifyAll. The original question isn't about them, but simply about calling a synchronized method with multiple threads.
I looked at the spec and it isn't clear (what's new?) on this point, however you can strongly infer from reading it that the behavior is the same as with notify and notifyAll. That is, if T1 is executing method foo that is synchronized and T2, T3, T4, and T5 call foo, in that order, and block, you cannot predict the order that they will execute foo once T1 releases the lock.
Peter Haggar
 
Peter Haggar
author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just traded email with Gilad Bracha, the author of the 2nd ed. of the JLS and my assumption was correct. The waiting threads on a synchronized method or block will behave just like I described for waiting threads when you call notify/notifyAll. You have no control over which thread will execute and it is not necessarily the one with the highest priority or the one that has been waiting the longest.
I hope this clears it up.
Peter Haggar
 
Alex Zhang
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry Peter, I am not going to challenge you nor your article.
But we can hardly say that a higher priority thread must be the one being run prior than the one with low priority.
It all depends on the implementation of the thread scheduler. And it relies on the VM implementation.
Normally speaking U are absolutely correct, but there is no guarantee.
Please have a look here for details:
http://java.sun.com/docs/books/tutorial/essential/threads/priority.html
 
Amit Rosner
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all I would like to thank you all (Jeremy Hare , jason adam , Alex Zhang and Peter Haggar ) for taking the time to discuss my question. I didn't actually think that so many people would be interested in it.
So I understand from all of you that the queuing phenomenon I witnessed was due to the VM implementation (I run on w2k) and not specified by the spec.
Which brings me to the starting point of the discussing - if queuing is not guaranteed, how can I force it?
 
Peter Haggar
author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alex Zhang:
But we can hardly say that a higher priority thread must be the one being run prior than the one with low priority.


I didn't say this. You are correct. Re-read my posts.


It all depends on the implementation of the thread scheduler. And it relies on the VM implementation.


Correct. Again, we don't disagree.


Normally speaking U are absolutely correct, but there is no guarantee.
Please have a look here for details:
http://java.sun.com/docs/books/tutorial/essential/threads/priority.html


I took a look and it doesn't say anything different from what I've said...namely that the highest priority thread isn't necessarily the one that is running at any given time.
I re-read my posts and they seemed clear to me. What is it I said that made you think I implied a guarantee?
Peter Haggar
 
Alex Zhang
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry Peter, just has verbal problem! We actually want to express the same idea, may be I have wrongly caught the meanings of the words!
Pls forgive my rudeness!!! :roll: :roll:
 
Peter Haggar
author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alex Zhang:
Sorry Peter, just has verbal problem! We actually want to express the same idea, may be I have wrongly caught the meanings of the words!
Pls forgive my rudeness!!! :roll: :roll:


Alex, No problem...you were not rude. I'm just glad we both see it the same way.
This has been a good thread because the answer to the original question is not clearly defined in the JLS.
Peter Haggar
 
Honk if you love justice! And honk twice for tiny ads!
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic