threads and shared objects

[martin]

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]

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.

 

[Oliver Wong]

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?

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

 

[martin]

Mike and Oliver: thank you!
Martin

 

[A. Bolmarcich]

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?

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.

 

[VisionSet]

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?

 

[blmblm]

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.

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.)

 

[VisionSet]

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.