threads and shared objects

Discussion in 'Java' started by martin, May 24, 2006.

  1. martin

    martin Guest

    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
     
    martin, May 24, 2006
    #1
    1. Advertisements

  2. martin

    VisionSet Guest

    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.
     
    VisionSet, May 24, 2006
    #2
    1. Advertisements

  3. martin

    Oliver Wong Guest

    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
     
    Oliver Wong, May 24, 2006
    #3
  4. martin

    martin Guest

    Mike and Oliver: thank you!
    Martin
     
    martin, May 24, 2006
    #4
  5. 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.
     
    A. Bolmarcich, May 24, 2006
    #5
  6. martin

    VisionSet Guest

    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?
     
    VisionSet, May 24, 2006
    #6
  7. martin

    blmblm Guest

    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.)
     
    blmblm, May 24, 2006
    #7
  8. martin

    VisionSet Guest

    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.
     
    VisionSet, May 24, 2006
    #8
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.