basic thread issue

[jim]

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

 

[Pierre Vigneras]

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/

 

[Michael Borgwardt]

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.

 

[Matt Humphrey]

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

 

[Lee Fesperman]

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.

 

[Guest]

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

 

[Matt Humphrey]

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 (e-mail address removed) http://www.iviz.com/

 

[Lee Fesperman]

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]

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.

 

[Chris Uppal]

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

 

[Mark Thornton]

Lee Fesperman wrote:




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)

The Java Memory Model is being rewritten to prevent the possibility of
seeing immutable objects like String appear to change when seen from
another thread.

http://www.jcp.org/en/jsr/detail?id=133

Mark Thornton

 

[Chris Uppal]

The Java Memory Model is being rewritten to prevent the possibility of
seeing immutable objects like String appear to change when seen from
another thread.

http://www.jcp.org/en/jsr/detail?id=133

I'm looking forward to seeing the results of this work. It seems to be a long
time coming (not surprisingly).

Still, I haven't been able to find anything that supports your assertion, do
you have a specific reference ? I'm not saying you are wrong, I just can't
find anything except fairly early *suggestions* as to what the new spec should
say, and even they don't, as far as I can tell yet (I've only just found some
of the stuff), directly address constructors (except in the case of final
fields).

-- chris

 

[Mark Thornton]

Mark Thornton wrote:




I'm looking forward to seeing the results of this work. It seems to be a long
time coming (not surprisingly).

Still, I haven't been able to find anything that supports your assertion, do
you have a specific reference ? I'm not saying you are wrong, I just can't
find anything except fairly early *suggestions* as to what the new spec should
say, and even they don't, as far as I can tell yet (I've only just found some
of the stuff), directly address constructors (except in the case of final
fields).

There is a mailing list for memory model issues (and an archive of it)
at http://www.cs.umd.edu/~pugh/java/memoryModel/archive/
As I understand it, the fix to String would include making its fields
final. In any case the public review documents should be out soon.

Mark Thornton

 

[Chris Uppal]

There is a mailing list for memory model issues (and an archive of it)
at http://www.cs.umd.edu/~pugh/java/memoryModel/archive/
As I understand it, the fix to String would include making its fields
final. In any case the public review documents should be out soon.

Thank you.

The idea does indeed seem to be that immutable-by-design objects can have
threadsafe construction by making all their fields final. Quite cool.

Leaves a problem for other constructors, though. And even for semi-immutable
objects like the Sun implementation of String (which uses lazy -- i.e. still
not threadsafe, even with the upcoming semantics -- initialisation of its
cached hashCode()).

-- chris

 

[Mark Thornton]

Mark Thornton wrote:




Thank you.

The idea does indeed seem to be that immutable-by-design objects can have
threadsafe construction by making all their fields final. Quite cool.

Leaves a problem for other constructors, though. And even for semi-immutable
objects like the Sun implementation of String (which uses lazy -- i.e. still
not threadsafe, even with the upcoming semantics -- initialisation of its
cached hashCode()).

-- chris

The cached hashcode isn't a problem --- the worst that can happen is
that two (or more threads) will each calculate the same value. That is
the result will always be the same, just some unnecessary work may occur.

Mark

 

[Chris Uppal]

The cached hashcode isn't a problem --- the worst that can happen is
that two (or more threads) will each calculate the same value. That is
the result will always be the same, just some unnecessary work may occur.

Yes, indeed. It was only intended as an illustration.

However, thinking about it more, I don't think it *is* as straightforward as
all that. As far as I can see, the only reason why the initial zero value of
the hash is guaranteed to be visible is that the time it is set has a 'happen
before' relationship with the setting of the final variables in the local
thread, and they in turn are set 'before' the constructor returns. Since the
hash is zeroed before the synchronized block that initialises the final
variables*, the value is guaranteed to be properly propagated to other threads
too (piggy-backed as it were).

But if the count's "null" value were, say, -1 then that would have to be set by
code, and whether the new values's propagation was guaranteed would depend on
exactly when it happened relative to the setting of the finals. A delicate and
fragile business...

public class String
{
private final char[] m_value;
private int m_hash;

public String(char[] value)
{
m_value = copy(value);
m_hash = -1; // oops...
}
// etc
}

At least, that's how it seems to me now -- I admit I'm still working through
this new stuff.

-- chris

[*] I'm assuming there has to be one, or something very similar -- I don't see
how to implement the proposed semantics without it.