• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Local variables always thread safe ?

 
James Clarke
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

Are local variables always thread safe ? and if so why is this ?
My understanding is it is because they are not stored on the stack. But if they are not on the stack, where are they stored ?

thanks in advance,

J.C
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Local variables are thread-safe, in that no other thread can get at them. You may consider them to be stored on the stack for that thread, though Java programmers should rarely concern themselves about such low-level details.

You have to be careful not to read too much into this "thread-safe" nature of local variables. Most importantly, if your local variable is an object reference, then it is thread-safe only to the extent that another thread can't get in and change the object reference to point to another object. But, if another thread has its own reference to the same object, it CAN get in and change the object.

In Java, unlike C++ and some other languages, you cannot have an object as a local variable on a stack. Java objects are always on the heap.
[ August 15, 2006: Message edited by: Peter Chase ]
 
Paul Clapham
Sheriff
Posts: 21107
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to expand on what Peter wrote, if you think of thread safety as applying to variables, you are thinking about it the wrong way. Thread safety is always about regulating simultaneous access to objects. So if you have a local variable and assign it an object reference like this:then it may contain a reference to an object that is also referenced by other variables in other threads. And in such a case you would need to consider thread safety issues. Whereas if you assigned it an object reference like this:then no other variable anywhere can contain a reference to that new object. In this case no thread safety issues arise -- until you assign a reference to that object to something outside the scope of the local variable...
[ August 15, 2006: Message edited by: Paul Clapham ]
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Local primitives are always thread safe. Objects are never local, thus can never be assumed thread-safe because of localness.
 
James Clarke
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the response guys,

Just for clarification can you confirm the following:

Local variables are stored on the stack, each thread has a reference to its own set of variables on the stack, so local variables are thread safe.

Objects are stored on the heap and can be accessed by multiple threads so are not thread safe.
How can the object on the heap be accessed by multiple threads unless something like JNDI is used ?

thanks in advance,

James


Objects are never local, thus can never be assumed thread-safe because of localness.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Clarke:
Local variables are stored on the stack, each thread has a reference to its own set of variables on the stack, so local variables are thread safe.


Yes. In fact, each thread has its own stack.


How can the object on the heap be accessed by multiple threads unless something like JNDI is used ?


You can pass references to that object around between different threads.

As long as you don't do that, objects are thread safe, too, of course.
 
James Clarke
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks, much appreciated.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paul Clapham:
if you assigned it an object reference like this:then no other variable anywhere can contain a reference to that new object. In this case no thread safety issues arise -- until you assign a reference to that object to something outside the scope of the local variable...


Usually true, I agree, but not always. The constructor of Thing is quite at liberty to go find other pre-existing objects and interact with them. Thing's constructor could even pass a reference to itself to another object, so that object could do stuff to the Thing in another thread.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Clarke:
Thanks for the response guys,

Just for clarification can you confirm the following:

Local variables are stored on the stack, each thread has a reference to its own set of variables on the stack, so local variables are thread safe.

Objects are stored on the heap and can be accessed by multiple threads so are not thread safe.
How can the object on the heap be accessed by multiple threads unless something like JNDI is used ?

thanks in advance,

James


I would like for you to pay attention to your terms. I think there are some issues there.

You can not start talking about 'local' variables, then shift to talking about objects. This is like baskets vs. apples. Maybe you want to talk about variables that refer to primitives vs. variables that refer to objects?

Do you have c++ background?
 
Paul Clapham
Sheriff
Posts: 21107
32
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Chase:
Usually true, I agree, but not always...
Ah, yes. Another reason to not search out helpful-sounding mantras like "Local variables are always thread-safe", but instead to understand how things work.
[ August 16, 2006: Message edited by: Paul Clapham ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic