aspose file tools*
The moose likes Threads and Synchronization and the fly likes Copying final locks onto stack Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Copying final locks onto stack" Watch "Copying final locks onto stack" New topic
Author

Copying final locks onto stack

Luca Estrada
Greenhorn

Joined: Sep 20, 2006
Posts: 1
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
Sheriff

Joined: Sep 28, 2004
Posts: 19004
    
  40

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 ]

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
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.


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Edward Harned
Ranch Hand

Joined: Sep 19, 2005
Posts: 291

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.


Ed's latest article: A Java Parallel Calamity http://coopsoft.com/ar/Calamity2Article.html
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
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

Joined: Sep 19, 2005
Posts: 291

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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Copying final locks onto stack