This week's book giveaway is in the Performance forum.
We're giving away four copies of The Java Performance Companion and have Charlie Hunt, Monica Beckwith, Poonam Parhar, & Bengt Rutisson on-line!
See this thread for details.
Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

thread lock (monitor) question

 
James Quinton
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
refering to JLS 17.1, one Object only has one monitor. The monitor can be held by only one thread at a time. If a thread wants to access synchronized block, it must obtain the monitor.
Does that imply if a class has 2 synchronized methods (say methodA(), methodB()), if thread-1 is accessing methodA(), no any other thread can access methodB(), even though thread-1 is only accessing methodA() not methodB()?
[ October 14, 2006: Message edited by: James Quinton ]
 
Henry Wong
author
Marshal
Pie
Posts: 21212
81
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Quinton:
Does that imply if a class has 2 synchronized methods (say methodA(), methodB()), if thread-1 is accessing methodA(), no any other thread can access methodB(), even though thread-1 is only accessing methodA() not methodB()?


Forgetting about static methods for the moment... yes, that is correct. When a synchronized method is executing, all other threads will have to wait to access *any* synchronized methods.

Static methods are a bit different, since there is no "this" object, they use the class object instead.

Henry
 
Y Enev
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is the case if both methodA and methodB are non-static and they are invoked using the same instance. If one of the methods is static though, they can be called by two different threads.
The difference is that if a thread gets the lock of static synchronised methods it actually get the lock of the class. If the method is non-static the thread will get the lock of the object that called the synchronised method.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Referring to the previous post:
"If the method is non-static the thread will get the lock of the object that called the synchronised method."

You sure about that?
 
Y Enev
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Threads calling non-static synchronized methods in the same class will only block each other if they're invoked using the same instance. That's because they each lock on this instance, and if they're called using two different instances, they get two locks, which do not interfere with each other.


This is what is says in "SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055)" book by Kathy Sierra and Bert Bates. I just tried to say the same using fewer words.



[HENRY: Fixed quote tags]
[ October 14, 2006: Message edited by: Henry Wong ]
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To "Y",
the point I picked you up on was that you wrote "get the lock of the object that called the synchronised method". If a thread that is executing code in my object calls a synchronized method in the class of another object, the thread has to get the lock on the other object, not my own.

Did you mean "contains" the method rather than "called" the method?
[ October 15, 2006: Message edited by: Barry Gaunt ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic