This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Synchronization around instance variables Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Synchronization around instance variables" Watch "Synchronization around instance variables" New topic
Author

Synchronization around instance variables

Ted Bell
Ranch Hand

Joined: Jan 21, 2002
Posts: 52
Hi all,
Quick question about synchronizing around some instance variables. Mutiple threads may be modifying some of the fields on a single instance of the object. I don't want to synchronize the entire method because it is more restrictive than I need.
For example, take the User object and the User's name. Should I not synchronize access to the name field alone, in a syncronized bloack as below:


This sounds logical to me, but I seem to get a NullPointerException when the setName method is called, I assume because I should not synchronize around a null value? Better ways to do this?

Thanks.
Art
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Art
Just synchronize around the object itself instead of one of its members. Your method should look like this:

That way as long as the object itslef exists then the expression in synchronized will not return null.
hope that helps


Dave
Ted Bell
Ranch Hand

Joined: Jan 21, 2002
Posts: 52
Thanks Dave. But is this method of synchronizing overly restrictive in some cases? Does it not prevent access to the object as a whole, when all I cate about is controlling access to one particular field?
What if I want to protect the name field from thread collisions, but don't want to restrict a different thread from mutating the phoneNumber field at the same time?
Or am I just being overly paranoid?
By the way, I understand that marking a method as synchronized prevents any other method of that object from being called while in the synchronized method. If this is the case (and correct me if it is not) then would marking the setName method as synchronized have the same effect as the synchronized block around "this" as you indicate? just curious if there is a difference.
I have also read that it is really not necessary to synchronize getter methods. Is this true?
One more: I also found some postings that indicated that primitives (except for double and long) are atomic, and access to them does not need to be synchonized at all. Can someone confirm?

Thanks
Art
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Originally posted by Art Vandelay:
[QB] ... is this method of synchronizing overly restrictive in some cases? Does it not prevent access to the object as a whole, when all I cate about is controlling access to one particular field?
What if I want to protect the name field from thread collisions, but don't want to restrict a different thread from mutating the phoneNumber field at the same time?

synchronizing things this way is not overly restrictive it is just more specific than synchronizing on the entire method. The line 'synchronized(this) ' obtains the lock on the object refered to by this. At this point no other thread can access any other synchronized code belonging to that object. As far as I know there is no way to specifically restrict access to a member of a class - if there is then the code to determine exactly what a thread is trying to modify would probably take longer to execute than waiting a second for the lock on an object.

...would marking the setName method as synchronized have the same effect as the synchronized block around "this" as you indicate? just curious if there is a difference.

In this case there is really not much of a difference except that the lock is obtained only for one line of code instead of the entire method. Keep in mind though that the object in the synchronized arguments doesn't have to be this - you can always get the lock on a different object.

I have also read that it is really not necessary to synchronize getter methods. Is this true?

One of the main purposes of synchronizing is to prevent multiple threads from messing each other up by accessing/changing data while another thread is doing the same thing. In the case of getter methods it is up to you to decide - or the application designer. Do you need to be assured that any time you get a value you get the most current one? If so then you might want to synchronize your getters too. If it doesnt matter that you get a value while someone else is changing it then you needn't synchronize the getters.
hope that helps
 
wood burning stoves
 
subject: Synchronization around instance variables
 
Similar Threads
should not contain any special characters
newbie to JUn it
Question of memory consumption for variable
Java Rule Round Up: Question 80
\what is "this" mean ?