«

Do threads make contention to method varaibles? I remember threads can make
contention to instance variables. In order to protect instance variable
integrity, I can use synchronized as a method modifier or use synchronized
block inside method body. For a method, each thread has a different
allocated memory space. Is this right?

Jim

>>>>> "jim" == jim <> writes:

jim> Do threads make contention to method varaibles? I remember threads can
jim> make contention to instance variables. In order to protect instance
jim> variable integrity, I can use synchronized as a method modifier or use
jim> synchronized block inside method body. For a method, each thread has a
jim> different allocated memory space. Is this right?


Yes.



--
Pierre Vigneras
http://www.labri.fr/~vigneras/

Distributed Objects Systems
LaBRI
http://www.labri.fr/

jim wrote:
> Do threads make contention to method varaibles? I remember threads can make
> contention to instance variables. In order to protect instance variable
> integrity, I can use synchronized as a method modifier or use synchronized
> block inside method body. For a method, each thread has a different
> allocated memory space. Is this right?

local variables live on the stack, and each thread has its own stack, yes.

"jim" <> wrote in message
news:burjl4$ki6$...
> Do threads make contention to method varaibles? I remember threads can
make
> contention to instance variables. In order to protect instance variable
> integrity, I can use synchronized as a method modifier or use synchronized
> block inside method body. For a method, each thread has a different
> allocated memory space. Is this right?

Threads have contention for objects, not variables. It doesn't matter if
the object is accessed via its reference in an instance variable or a local
variable. If the object can be accessed from more than one thread, there
can be synchronization problems.

Having said that, local variables themselves are not shared across threads.
The value (primitive or object reference) that one thread sees for a local
variable has nothing to do with what a different thread sees. Whether two
variables refer to the same object or not is up to you. Each thread can see
a potentially different value for every local variable. As for objects, if
you have an object that can be accessed by only one thread at a time (by
whatever means possible), you will not have synchronization problems. The
difficulty, of course, is ensuring or proving that more than one thread
cannot or will not access the object at the same time. In that sense,
referencing an object from a local variable does not prevent contention in
the least.

Cheers,
Matt Humphrey

Matt Humphrey wrote:
>
> "jim" <> wrote in message
> news:burjl4$ki6$..
> > Do threads make contention to method varaibles? I remember threads can make
> > contention to instance variables. In order to protect instance variable
> > integrity, I can use synchronized as a method modifier or use synchronized
> > block inside method body. For a method, each thread has a different
> > allocated memory space. Is this right?
>
> Threads have contention for objects, not variables. It doesn't matter if
> the object is accessed via its reference in an instance variable or a local
> variable. If the object can be accessed from more than one thread, there
> can be synchronization problems.

You are incorrect. Aside from external resources, mutable variables (instance or class,
but not local) are the only reason for contention/synchronization between threads. For
example, there are no contention problems for immutable objects (String, Integer, ...)
because they contain no mutable instance variables.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

On Fri, 23 Jan 2004 20:49:02 +0000, Lee Fesperman wrote:

> Matt Humphrey wrote:
>>
>> "jim" <> wrote in message
>> news:burjl4$ki6$..
>> > Do threads make contention to method varaibles? I remember threads can
>> > make contention to instance variables. In order to protect instance
>> > variable integrity, I can use synchronized as a method modifier or use
>> > synchronized block inside method body. For a method, each thread has a
>> > different allocated memory space. Is this right?
>>
>> Threads have contention for objects, not variables. It doesn't matter
>> if the object is accessed via its reference in an instance variable or a
>> local variable. If the object can be accessed from more than one
>> thread, there can be synchronization problems.
>
> You are incorrect. Aside from external resources, mutable variables
> (instance or class, but not local) are the only reason for
> contention/synchronization between threads. For example, there are no
> contention problems for immutable objects (String, Integer, ...) because
> they contain no mutable instance variables.

The _reference_ of a local variable will never be changed by another
thread, true enough. However, any thread to which the _Object_ is visible
may alter the state of said object.

La'ie Techie

"Lee Fesperman" <> wrote in message
news:...
> Matt Humphrey wrote:
> >
> > "jim" <> wrote in message
> > news:burjl4$ki6$..
> > > Do threads make contention to method varaibles? I remember threads can
make
> > > contention to instance variables. In order to protect instance
variable
> > > integrity, I can use synchronized as a method modifier or use
synchronized
> > > block inside method body. For a method, each thread has a different
> > > allocated memory space. Is this right?
> >
> > Threads have contention for objects, not variables. It doesn't matter
if
> > the object is accessed via its reference in an instance variable or a
local
> > variable. If the object can be accessed from more than one thread,
there
> > can be synchronization problems.
>
> You are incorrect. Aside from external resources, mutable variables
(instance or class,
> but not local) are the only reason for contention/synchronization between
threads. For
> example, there are no contention problems for immutable objects (String,
Integer, ...)
> because they contain no mutable instance variables.

Thanks for pointing out that contention can occur on class variables. I
agree that contention can occur whenever more than one thread accesses a
shared data container (instance or class variable) that can change state.
However, I cite contention on objects because (other than class variables)
it can only happen when there is a shared reference and it doesn't matter
what kinds of variables the references are stored in. I often find that
people confuse the variable and the object and mistakenly believe that by
calling the methods of a typical object via a local or final variable means
the result will be threadsafe. Even calling the methods of an application's
immutable object (one with no mutable instance variables) can cause
contention if those variables ultimately refer to objects that are mutable
and shared.

Given that the goal is to eliminate contention in an application composed of
mutable objects and because objects that are not shared cannot have
contention, I recommend people consider how threads access shared objects.

Cheers,
Matt Humphrey http://www.iviz.com/

=?UTF-8?b?TMSByrtpZSBUZWNoaWU=?= wrote:
>
> On Fri, 23 Jan 2004 20:49:02 +0000, Lee Fesperman wrote:
>
> > Matt Humphrey wrote:
> >>
> >> "jim" <> wrote in message
> >> news:burjl4$ki6$.
> >> > Do threads make contention to method varaibles? I remember threads can
> >> > make contention to instance variables. In order to protect instance
> >> > variable integrity, I can use synchronized as a method modifier or use
> >> > synchronized block inside method body. For a method, each thread has a
> >> > different allocated memory space. Is this right?
> >>
> >> Threads have contention for objects, not variables. It doesn't matter
> >> if the object is accessed via its reference in an instance variable or a
> >> local variable. If the object can be accessed from more than one
> >> thread, there can be synchronization problems.
> >
> > You are incorrect. Aside from external resources, mutable variables
> > (instance or class, but not local) are the only reason for
> > contention/synchronization between threads. For example, there are no
> > contention problems for immutable objects (String, Integer, ...) because
> > they contain no mutable instance variables.
>
> The _reference_ of a local variable will never be changed by another
> thread, true enough. However, any thread to which the _Object_ is visible
> may alter the state of said object.

The state of the object is stored in instance (and class) variables.

A thread may only alter the state of a 'visible' object if it has access to fields
and/or to methods which alter state. IOW, visibility is required, but it is not the only
requirement.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

Matt Humphrey wrote:
>
> "Lee Fesperman" <> wrote in message
> news:..
> > Matt Humphrey wrote:
> > > ...
> >
> > You are incorrect. Aside from external resources, mutable variables
> > (instance or class, but not local) are the only reason for
> > contention/synchronization between threads. For example,
> > there are no contention problems for immutable objects (String,
> > Integer, ...) because they contain no mutable instance variables.
>
> Thanks for pointing out that contention can occur on class variables. I
> agree that contention can occur whenever more than one thread accesses a
> shared data container (instance or class variable) that can change state.
> However, I cite contention on objects because (other than class variables)
> it can only happen when there is a shared reference and it doesn't matter
> what kinds of variables the references are stored in. I often find that
> people confuse the variable and the object and mistakenly believe that by
> calling the methods of a typical object via a local or final variable means
> the result will be threadsafe. Even calling the methods of an application's
> immutable object (one with no mutable instance variables) can cause
> contention if those variables ultimately refer to objects that are mutable
> and shared.

You shouldn't confuse people further by distorting what's really happening. You said
"Threads have contention for objects, not variables." That is wrong.

I wouldn't call an object that allows you to change the objects it references immutable.
For instance, java.lang.String contains a char array that is both mutable and shared (by
other String objects), however there is no contention because no one can actually change
the contents of the array.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

Lee Fesperman wrote:

> For example, there are no
> contention problems for immutable objects (String, Integer, ...) because
> they contain no mutable instance variables.

This is not strictly true, at least not according to my understanding of the
spec.

It's a bit off-topic for this thread, but consider:

Thread A constructs a new string:
-- (internally) creates and initialises a char array.
-- (internally) assigns a ref to that array to the field in the new String
object

Thread A assigns a reference to that String to a shared, volatile, location.

Thread B reads that location, since the location is volatile it guaranteed to
see the ref to the new object.

Thread B tries to use the String which (internally) reads the char array.
Potential problem, there is nothing to ensure that the char array, or its
contents, are yet visible to thread B; indeed there's no guarantee that the
String object "pointed to" by the reference is valid itself. That's because
neither thread has used a 'synchronized' block or method, and hence there is no
guarantee that their two views of memory are consistent.

As I understand it, synchronization is *always* necessary between threads, even
if all the shared objects are immutable once constructed. (Though it would be
OK if all the objects were created in a thread-safe way first)

-- chris