• 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

question: synchronized and non-syncronized methods

 
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Moving this to the threads forum (so that all the crossposts will be together... )

Henry
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic