This week's giveaway is in the Threads forum.
We're giving away four copies of Java Concurrency Live Lessons and have Doug Schmidt on-line!
See this thread for details.
Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

question: synchronized and non-syncronized methods  RSS feed

 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A question for the real profis.

When a thread enters a synchronized method (or block) and locks the object, what happens when a non-synchronized method is called within this synchronized block? Does the thread give ups its lock? Or does it wait until leaving the synchronized method (or block)?

In other words, are non-synchronized methods only non-synchronized when called directly, but are "synchronization-supporting" (in the sense that they keep the established lock) as long as they are called from a synchronized context?

This may be a tough question. Be honest, if you are not sure about the answer.

Thanks.

My guess is that the lock is released only when the entire synchronized block is finished, regardless of what types of methods are called inside the block.

Is my question clear?
[ July 13, 2006: Message edited by: Douglas Chorpita ]
 
ram gaurav
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yups....

The thing is that when an Thread locks on synchronized block , and when it calls a non synchronized methord from that , that does not effect that , all threads can call non synchronized methords concurrently ..... and it does not effect that you are calling it from where , at this time lock is only hold by the same object.

Hope this help you
 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't understand your answer, Ram.

Threads hold locks on objects. Objects don't hold locks. Objects get locked.
 
Henry Wong
author
Sheriff
Posts: 22866
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving this to the threads forum (so that all the crossposts will be together... )

Henry
 
Henry Wong
author
Sheriff
Posts: 22866
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you call a non-synchronized method, the method is simply called. It does not try to acquire the lock, it does not free the lock, it simply calls the method. So if a thread that already owns the lock calls a non-synchronized method, it will still own the lock during the method.

Henry
 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks so much, Henry.

Based on what you are saying, shared objects should make sensitive methods (i.e. methods that change the object's internal state) synchronized, but can leave non-sensitive methods (getters, for example) un-synchronized.

The method setPriority() in Thread is not synchronized. This means you can (within ThreadA, for example) set the thread priority to 7, but can't be sure (when it's true that other threads can access this Thread object) that one line later in the code that the priority will still be 7. ThreadA could stop running. ThreadB could change the priority to 4, for example. When the ThreadA continues the priority has been changed.


Am I right?
[ July 13, 2006: Message edited by: Douglas Chorpita ]
 
Henry Wong
author
Sheriff
Posts: 22866
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Based on what you are saying, shared objects should make sensitive methods (i.e. methods that change the object's internal state) synchronized, but can leave non-sensitive methods (getters, for example) un-synchronized.


Hmmm.... So based on what you are saying setters should be synchronized and getters not? Think about it. What happens when a setter is half-way through changing a complex set of variables, and the getter is called?

The method setPriority() in Thread is not synchronized. This means you can (within ThreadA, for example) set the thread priority to 7, but can't be sure (when it's true that other threads can access this Thread object) that one line later in the code that the priority will still be 7. ThreadA could stop running. ThreadB could change the priority to 4, for example. When the ThreadA continues the priority has been changed.


Actually, it is not easy to tell if a method uses synchronization or not. If a method is synchronized, then fine... But if it is not, it could be using synchronized blocks of code, or calling other synchronized methods. Or in the case of Java 5, be using the new Lock class.

Henry
 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good point.

I guess it is pretty unpredictable.

It seems that I am just trying to come up with a simplified perception of how to designed shared objects. The truth seems to be that designing shared objects is very tricky and there are no clearly obvious rules about how to decide which methods should be synchronized.
 
Eitan Levi
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Douglas Chorpita:
Good point.

I guess it is pretty unpredictable.

It seems that I am just trying to come up with a simplified perception of how to designed shared objects. The truth seems to be that designing shared objects is very tricky and there are no clearly obvious rules about how to decide which methods should be synchronized.


I think a good general guideline is: If you're accessing something that can be changed by another thread, make sure it's synchronized. And by "accessing" I mean a read or a write.
 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes.

But, for example, the Thread object (which implements the Runnable interface and therefore is a candidate for sharing) has getter and setter methods that are not synchronized.

Some examples:

setPriority()
getPriority()
setName()

Why?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!