my dog learned polymorphism*
The moose likes Threads and Synchronization and the fly likes Which is better design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Which is better design" Watch "Which is better design" New topic
Author

Which is better design

Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194
I have 3 instance variables in my class. In a few methods var1 and var2 are used, in some var2 and var3 are used and in some var1 and var2 are used. For synchronization is it better to have lock on "this" or is it good to have three separate locks , one lock for each variable. What makes a good design decision ?
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Originally posted by Santhosh Jali:
I have 3 instance variables in my class. In a few methods var1 and var2 are used, in some var2 and var3 are used and in some var1 and var2 are used. For synchronization is it better to have lock on "this" or is it good to have three separate locks , one lock for each variable. What makes a good design decision ?


I like the granularity of more locks, one for each variable, or more appropriately one for each 'unit of data' which may mean multiple variables if they are always used together.

It is always best to keep you synchronized blocks as small as possible, and blocking as few threads as possible. Why block all thread's access to all data, when a method only needs 2 variables? Instead just lock those 2 variables so any method trying to use other data can do so.


Steve
Thomas Thevis
Ranch Hand

Joined: Sep 02, 2008
Posts: 87
Originally posted by Steve Luke:
I like the granularity of more locks, one for each variable, or more appropriately one for each 'unit of data'...

Agreed, but in the example from above, isn't it necessary to lock all variables at the same time to avoid dead locking? In other words, isn't the 'unit of work' all three variables at once?

Originally posted by Santhosh Jali:
In a few methods var1 and var2 are used, in some var2 and var3 are used and in some var1 and var2 are used.

Is this a typo and you meant var1 and var3 for kind of circular dependencies?

I guess in this specific eample it is easier to lock with 'this' instance. The multi lock overhead doesn't gain anything.

Other opinions?
Thomas


SCJP 5.0, SCJD in progress
Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194
Originally posted by Thomas Thevis:

Is this a typo and you meant var1 and var3 for kind of circular dependencies?

I guess in this specific eample it is easier to lock with 'this' instance. The multi lock overhead doesn't gain anything.

Other opinions?
Thomas


sorry it was a typo. combinations are var1 and var2, var2 and var3, var1 and var3
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

I concur with Steve's suggestion that the synchronization blocks must be as small as possible, however, there is one more factor that determines the monitor and that is how hot is the piece of code you are guarding?

So, if your code is invoked in huge numbers in most code paths, then optimizing synchronized blocks is a big plus, however, if it is not so, then, optimizing these blocks bring along a complexity in code and an overhead in maintenance.

Today, you may think that in a particular block you are using 2 variables and you take a particular monitor. Sometime down the line, one innocent developer adds a line of code that uses a variable that is guarded by some other monitor. So, now he/she would have to revisit the locking strategy and check all the concurrency cases, which makes it difficult to maintain.
So, optimizing synchronization depends on the frequency of invocation and expected concurrency levels of the code.
If the code is not expected to be too hot then its better to have it synchronized on "this" rather than different monitors.


apigee, a better way to API!
Srikanth Basa
Ranch Hand

Joined: Jun 06, 2005
Posts: 241
One must take into consideration that locking and unlocking has performance overhead. Whether you must lock on 'this' or have independent locks is a decision to be made based on the performance.

If you keep on locking and unlocking on individual members, you might feel that you have locks on the coarse grain level but on the other side, it could slow down the performance of your system.

If you lock on 'this' object you might be deferring the execution of certain code which can execute simultaneously without any damage.
[ October 06, 2008: Message edited by: Srikanth Basavaraju ]
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

Srikanth:
[QB]One must take into consideration that locking and unlocking has performance overhead.


With jdk5, an uncontended lock does not have any significant performance overhead. (This article gives you some more details)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Which is better design