• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Copying final locks onto stack

 
Luca Estrada
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking at the implementations of many of the new concurrent collection types in 5.0 Tiger, In many cases a final lock variable used by a class is copied to a final variable on the stack in a locking method e.g.

public class SomeClass
{
private ReentrantLock lock = new ReentrantLock();

public void someLockingMethod(...)
{
final Reentrant lock = this.lock;
lock.acquire();

// exclusively utilized resources guarded by lock
}
}

What is the benefit of this referencing the lock as a final on the stack over the heap?

thanks,

ls
 
Henry Wong
author
Marshal
Pie
Posts: 21489
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy "l4strada",

Welcome to the JavaRanch...

You may not have noticed that we have a policy on screen names here at the ranch. It must consist of a first name, a space, and a last name. It must also not be fictitious.

Unfortunately, your screen name does not seem to conform with this policy. Please take a moment to change it.


As for your question... from what code you have shown, there is no advantage in creating a new local variable that references the same object as the instance variable.

Thanks,
Henry


[HW: Thanks for fixing your screen name]
[ September 20, 2006: Message edited by: Henry Wong ]
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by l4strada:
What is the benefit of this referencing the lock as a final on the stack over the heap?

When I started doing Java, this type of thing was common. I was told that local variables are faster to access than object fields, so I should copy fields to local variables in situations where the field would be accessed several times in the method.

I'm not sure how true that is now.

If the field is not "final" and the program is multi-threaded, another difference between the local variable version and the field version is that changes to the field in another thread will not affect a particular invocation of the method.
 
Edward Harned
Ranch Hand
Posts: 291
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First of all, you are not copying the variable lock. Lock is an object and so all you are doing is taking a reference to the class variable.

lock and this.lock point to the same object.

If you had an int, then you would have a copy.

I'm not familiar with what you were taught about using local variables. Actually I've never heard of it before.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Edward Harned:
First of all, you are not copying the variable lock. Lock is an object and so all you are doing is taking a reference to the class variable.

lock and this.lock point to the same object.

If you had an int, then you would have a copy.


Er, what? The code does copy the reference, from the SomeClass object on the heap to the current thread's stack. I never meant to imply that the ReentrantLock object itself was copied.

I suspect we both meant the same thing, but phrased it differently.
 
Edward Harned
Ranch Hand
Posts: 291
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To be technical on referencing instance fields:

Your methods should not reference instance fields directly. You should use a getter for instance fields, such as:
getLock().acquire();
This way your methods are not concerned with the actual object itself.

Consider if you upgrade the Lock object to an atomic reference. Then using lock.acquire() will not compile. You need lock.get(). Putting this into a getter relieves the using methods of knowing just how the object is stored.

Now whether the object lives on a heap or stack and the number of computer machine instructions it takes to access it may seem trivial. With the optimizing compilers we have today, the reference may even remain in a register or cache.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic