Hi,
I've a question concerning threads and shared objects:
Assume an object of the following class SharedObject
is used by two different threads.
class SharedObject
{
private String s;
public void method (int i)
{
// preparation code (value of i never changes)
synchronized (this)
{
// do something with member s
// and use local variable i
// (value of i never changes)
}
// some other code (value of i never changes)
}
}
What I know is that access to member s should
be protected either by defining the whole method
synchronized or by putting a synchronized block
around the the critical sections of the method.
But what about the local variable i, if i use
a synchronized block and a thread is interrupted
during the preparation code?
Example:
...
SharedObject s;
...
// thread1 calls
s.method(5);
// thread2 calls
s.method(10);
...
assume thread1 is interrupted during the preparation
code and thread2 becomes active. Before thread2
finishes with s.method(10) it's interrupted and
thread1 becomes active again.
What is the value of i now (5 or 10)?
I did some tests whith many thread-instances using
a shared object and it seems, that local variables are
created separately for each thread.
Is this right?
Can i rely on this, or does it depend on the implementation of the JVM?
Is there a separate stack of local variables for each thread?
Maybe someone could explain that?
Thanks in advance!
Martin
VisionSet - 24 May 2006 18:31 GMT
> But what about the local variable i,
All calls to any method get their own copy of local variables.
That is primitives are an implicit copy by value, objects are an explicit
object copy by value (well you do new... don't you, or get it from somewhere
that does it on you behalf).
So no threading issues.
--
Mike W
martin - 24 May 2006 18:41 GMT
Mike and Oliver: thank you!
Martin
blmblm@myrealbox.com - 24 May 2006 19:26 GMT
>> But what about the local variable i,
>
[quoted text clipped - 3 lines]
>that does it on you behalf).
>So no threading issues.
Careful there.
Agreed about each call to a method getting a fresh "copy" of local
variables.
Agreed also that parameters are passed by value, so a called method
gets a copy of the caller's variable.
But when you write "explicit object copy by value", what do you mean?
surely *not* that non-primitive parameters are passed in a way that
involves copying the whole object, since that isn't what happens.
(Indeed, non-primitive variables are *references to objects* rather
than objects, and what's copied is the reference, not the object.
Etc., etc.)

Signature
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
VisionSet - 24 May 2006 19:33 GMT
> >> But what about the local variable i,
> >
[quoted text clipped - 6 lines]
> surely *not* that non-primitive parameters are passed in a way that
> involves copying the whole object...
No correct, I don't mean that.
I mean with:
void meth() {
Object obj = new Object();
}
each call creates a new Object. Though I see how my terminology was
misleading.
--
Mike W
Oliver Wong - 24 May 2006 18:33 GMT
> Hi,
>
[quoted text clipped - 52 lines]
> Is there a separate stack of local variables for each thread?
> Maybe someone could explain that?
Local variables are not shared across threads. The reason being is that
they exist on the stack, and each thread has their own stack. Objects (and
their fields) exists on the heap, and so are shared between threads.
- Oliver
VisionSet - 24 May 2006 19:07 GMT
> Local variables are not shared across threads. The reason being is that
> they exist on the stack, and each thread has their own stack. Objects (and
> their fields) exists on the heap, and so are shared between threads.
Surely this is a calling issue not a thread issue. Even with one thread
local variables will exist for every method call. Whilst your answers are
correct, I believe mine to be to the point. Or have I got that wrong?
--
Mike W
A. Bolmarcich - 24 May 2006 18:45 GMT
[snip]
> I did some tests whith many thread-instances using
> a shared object and it seems, that local variables are
[quoted text clipped - 3 lines]
> Is there a separate stack of local variables for each thread?
> Maybe someone could explain that?
According to section 3.5.2 "Java Stack" in the first edition of "The
Java Virtual Machine Specification":
Each Java Virtual Machine thread (§ 2.17) has a private Java
stack, created at the same time as the thread. A Java stack stores
Java Virtual Machine frames (§ 3.6). The Java stack is
equivalent to the stack of a conventional programming language,
such a C: it holds local variables and partial results, and plays
a part in method invocation and return.