basic thread issue

Discussion in 'Java' started by jim, Jan 23, 2004.

  1. jim

    jim Guest

    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, Jan 23, 2004
    #1
    1. Advertising

  2. >>>>> "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/
     
    Pierre Vigneras, Jan 23, 2004
    #2
    1. Advertising

  3. 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.
     
    Michael Borgwardt, Jan 23, 2004
    #3
  4. "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, Jan 23, 2004
    #4
  5. 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)
     
    Lee Fesperman, Jan 23, 2004
    #5
  6. 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
     
    =?UTF-8?b?TMSByrtpZSBUZWNoaWU=?=, Jan 24, 2004
    #6
  7. "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/
     
    Matt Humphrey, Jan 24, 2004
    #7
  8. =?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)
     
    Lee Fesperman, Jan 24, 2004
    #8
  9. 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, Jan 24, 2004
    #9
  10. jim

    Chris Uppal Guest

    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
     
    Chris Uppal, Jan 24, 2004
    #10
  11. Chris Uppal wrote:
    > 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)
    >


    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
     
    Mark Thornton, Jan 24, 2004
    #11
  12. jim

    Chris Uppal Guest

    Mark Thornton wrote:

    > 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
     
    Chris Uppal, Jan 24, 2004
    #12
  13. Chris Uppal wrote:

    > Mark Thornton wrote:
    >
    >
    >>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).
    >


    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
     
    Mark Thornton, Jan 24, 2004
    #13
  14. jim

    Chris Uppal Guest

    Mark Thornton wrote:

    > 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
     
    Chris Uppal, Jan 25, 2004
    #14
  15. Chris Uppal wrote:
    > Mark Thornton wrote:
    >
    >
    >>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
    >
    >


    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
     
    Mark Thornton, Jan 25, 2004
    #15
  16. jim

    Chris Uppal Guest

    Mark Thornton wrote:

    > 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.
     
    Chris Uppal, Jan 26, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. john
    Replies:
    4
    Views:
    578
    Lee Fesperman
    Jun 3, 2005
  2. francisl
    Replies:
    0
    Views:
    454
    francisl
    Jan 21, 2005
  3. Engineer
    Replies:
    6
    Views:
    624
    Jeremy Bowers
    May 1, 2005
  4. Replies:
    0
    Views:
    434
  5. Srini
    Replies:
    11
    Views:
    969
    Arne Vajhøj
    Jun 1, 2008
Loading...

Share This Page