Two more multithreading questions

Discussion in 'Java' started by Knute Johnson, Jan 30, 2007.

  1. I've got two specific scenarios I want to ask about:

    1) I have a class with an instance variable that is a reference to a
    JDialog. In one thread I create new instances of JDialog and make them
    visible. They might get closed in this thread as well. In another
    thread I close the JDialog using the class instance variable. To ensure
    that my dialog closing thread always has a reference to the current
    dialog I created the instance variable with volatile. Is this adequate
    to guarantee that my closing thread always has a reference to the latest
    dialog?

    2) If I want to access/modify an Object in two threads, can I use a
    reference to any Object in the synchronize statement to do that? It
    doesn't have to be the reference to the Object that I am trying to
    protect as long as the accesses are all in synchronized blocks?

    Thanks very much,

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 30, 2007
    #1
    1. Advertising

  2. Knute Johnson

    hiwa Guest

    On Jan 30, 12:53 pm, Knute Johnson <>
    wrote:
    > I've got two specific scenarios I want to ask about:
    >
    > 1) I have a class with an instance variable that is a reference to a
    > JDialog. In one thread I create new instances of JDialog and make them
    > visible. They might get closed in this thread as well. In another
    > thread I close the JDialog using the class instance variable. To ensure
    > that my dialog closing thread always has a reference to the current
    > dialog I created the instance variable with volatile. Is this adequate
    > to guarantee that my closing thread always has a reference to the latest
    > dialog?
    >
    > 2) If I want to access/modify an Object in two threads, can I use a
    > reference to any Object in the synchronize statement to do that? It
    > doesn't have to be the reference to the Object that I am trying to
    > protect as long as the accesses are all in synchronized blocks?
    >
    > Thanks very much,
    >
    > --
    >
    > Knute Johnson
    > email s/nospam/knute/


    Q 1) may need some code for me to understand.
    For Q 2), if you mean
    synchronized(obj){...} construct,
    'obj' can be anything. The 'obj' is not protected
    by this construct.
    hiwa, Jan 30, 2007
    #2
    1. Advertising

  3. Knute Johnson wrote:
    > I've got two specific scenarios I want to ask about:
    >
    > 1) I have a class with an instance variable that is a reference to a
    > JDialog. In one thread I create new instances of JDialog and make them
    > visible. They might get closed in this thread as well. In another
    > thread I close the JDialog using the class instance variable. To ensure
    > that my dialog closing thread always has a reference to the current
    > dialog I created the instance variable with volatile. Is this adequate
    > to guarantee that my closing thread always has a reference to the latest
    > dialog?


    I believe most javax.swing component access is supposed to be done in
    the event handling thread anyway. Swing was not designed to be
    multithread-safe.

    > 2) If I want to access/modify an Object in two threads, can I use a
    > reference to any Object in the synchronize statement to do that? It
    > doesn't have to be the reference to the Object that I am trying to
    > protect as long as the accesses are all in synchronized blocks?


    Two threads can be in synchronized blocks at the same time, as long as
    they are synchronized on different objects. You don't have to use the
    object you are protecting, but all accesses to that object must be
    synchronized on the same lock object.

    Patricia
    Patricia Shanahan, Jan 30, 2007
    #3
  4. Patricia Shanahan wrote:
    > Knute Johnson wrote:
    >> I've got two specific scenarios I want to ask about:
    >>
    >> 1) I have a class with an instance variable that is a reference to a
    >> JDialog. In one thread I create new instances of JDialog and make
    >> them visible. They might get closed in this thread as well. In
    >> another thread I close the JDialog using the class instance variable.
    >> To ensure that my dialog closing thread always has a reference to the
    >> current dialog I created the instance variable with volatile. Is this
    >> adequate to guarantee that my closing thread always has a reference to
    >> the latest dialog?

    >
    > I believe most javax.swing component access is supposed to be done in
    > the event handling thread anyway. Swing was not designed to be
    > multithread-safe.
    >


    Sorry, bad example. Say it is an Integer that is being created in one
    thread and in the other you are using the intValue() method.

    Thanks,

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 30, 2007
    #4
  5. Knute Johnson

    Daniel Pitts Guest

    On Jan 30, 9:44 am, Knute Johnson <>
    wrote:
    > Patricia Shanahan wrote:
    > > Knute Johnson wrote:
    > >> I've got two specific scenarios I want to ask about:

    >
    > >> 1) I have a class with an instance variable that is a reference to a
    > >> JDialog. In one thread I create new instances of JDialog and make
    > >> them visible. They might get closed in this thread as well. In
    > >> another thread I close the JDialog using the class instance variable.
    > >> To ensure that my dialog closing thread always has a reference to the
    > >> current dialog I created the instance variable with volatile. Is this
    > >> adequate to guarantee that my closing thread always has a reference to
    > >> the latest dialog?

    >
    > > I believe most javax.swing component access is supposed to be done in
    > > the event handling thread anyway. Swing was not designed to be
    > > multithread-safe.

    >
    > Sorry, bad example. Say it is an Integer that is being created in one
    > thread and in the other you are using the intValue() method.
    >
    > Thanks,
    >
    > --
    >
    > Knute Johnson
    > email s/nospam/knute/



    Integer is a bad example too, since it is immutable, which means onces
    its created, its value doesn't change.
    A good example might be a File object.

    Thread W can alter the file object, and Thread R can query it.
    The safest way to insure that your Thread R only sees what its
    supposed to is to wrap bother the object modifying and object querying
    code in synchronize blocks that sync on the same object O. That
    object O can be ANY object.

    public class ThreadSafeFileAccessor {
    private final Object sync = new Object();
    private File file = new File();
    public void modifyFile() {
    synchronize(sync) {
    // do modification of file
    }
    }

    public String queryFile() {
    synchronize(sync) {
    return file.toString();
    }
    }
    }

    Also be aware that Java 1.5 includes a new locking mechanism and other
    concurrency utilities which gives you more fine grained control over
    thread synchronization.
    <http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-
    summary.html>

    Good luck :)
    Daniel Pitts, Jan 30, 2007
    #5
  6. Daniel Pitts wrote:
    > On Jan 30, 9:44 am, Knute Johnson <>
    > wrote:
    >> Patricia Shanahan wrote:
    >>> Knute Johnson wrote:
    >>>> I've got two specific scenarios I want to ask about:
    >>>> 1) I have a class with an instance variable that is a reference to a
    >>>> JDialog. In one thread I create new instances of JDialog and make
    >>>> them visible. They might get closed in this thread as well. In
    >>>> another thread I close the JDialog using the class instance variable.
    >>>> To ensure that my dialog closing thread always has a reference to the
    >>>> current dialog I created the instance variable with volatile. Is this
    >>>> adequate to guarantee that my closing thread always has a reference to
    >>>> the latest dialog?
    >>> I believe most javax.swing component access is supposed to be done in
    >>> the event handling thread anyway. Swing was not designed to be
    >>> multithread-safe.

    >> Sorry, bad example. Say it is an Integer that is being created in one
    >> thread and in the other you are using the intValue() method.
    >>
    >> Thanks,
    >>
    >> --
    >>
    >> Knute Johnson
    >> email s/nospam/knute/

    >
    >
    > Integer is a bad example too, since it is immutable, which means onces
    > its created, its value doesn't change.
    > A good example might be a File object.
    >
    > Thread W can alter the file object, and Thread R can query it.
    > The safest way to insure that your Thread R only sees what its
    > supposed to is to wrap bother the object modifying and object querying
    > code in synchronize blocks that sync on the same object O. That
    > object O can be ANY object.
    >
    > public class ThreadSafeFileAccessor {
    > private final Object sync = new Object();
    > private File file = new File();
    > public void modifyFile() {
    > synchronize(sync) {
    > // do modification of file
    > }
    > }
    >
    > public String queryFile() {
    > synchronize(sync) {
    > return file.toString();
    > }
    > }
    > }
    >
    > Also be aware that Java 1.5 includes a new locking mechanism and other
    > concurrency utilities which gives you more fine grained control over
    > thread synchronization.
    > <http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-
    > summary.html>
    >
    > Good luck :)
    >


    Daniel:

    Thank you very much for your response but it doesn't really answer my
    question. As to the immutable, I'm not muting. So let me set the
    scenario again.

    Class with instance variable that is reference to Integer. One thread
    makes new Integers and assigns them to the instance variable. The other
    thread calls some method on the Integer. I want to know if making the
    variable volatile will guarantee that the second thread always sees the
    latest integer created by the first thread.

    I know that I can wrap both pieces of code in a synchronized block but I
    want to understand my question.

    Thanks very much,

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 30, 2007
    #6
  7. Knute Johnson

    Daniel Pitts Guest

    On Jan 30, 10:55 am, Knute Johnson <>
    wrote:
    > Daniel Pitts wrote:
    > > On Jan 30, 9:44 am, Knute Johnson <>
    > > wrote:
    > >> Patricia Shanahan wrote:
    > >>> Knute Johnson wrote:
    > >>>> I've got two specific scenarios I want to ask about:
    > >>>> 1) I have a class with an instance variable that is a reference to a
    > >>>> JDialog. In one thread I create new instances of JDialog and make
    > >>>> them visible. They might get closed in this thread as well. In
    > >>>> another thread I close the JDialog using the class instance variable.
    > >>>> To ensure that my dialog closing thread always has a reference to the
    > >>>> current dialog I created the instance variable with volatile. Is this
    > >>>> adequate to guarantee that my closing thread always has a reference to
    > >>>> the latest dialog?
    > >>> I believe most javax.swing component access is supposed to be done in
    > >>> the event handling thread anyway. Swing was not designed to be
    > >>> multithread-safe.
    > >> Sorry, bad example. Say it is an Integer that is being created in one
    > >> thread and in the other you are using the intValue() method.

    >
    > >> Thanks,

    >
    > >> --

    >
    > >> Knute Johnson
    > >> email s/nospam/knute/

    >
    > > Integer is a bad example too, since it is immutable, which means onces
    > > its created, its value doesn't change.
    > > A good example might be a File object.

    >
    > > Thread W can alter the file object, and Thread R can query it.
    > > The safest way to insure that your Thread R only sees what its
    > > supposed to is to wrap bother the object modifying and object querying
    > > code in synchronize blocks that sync on the same object O. That
    > > object O can be ANY object.

    >
    > > public class ThreadSafeFileAccessor {
    > > private final Object sync = new Object();
    > > private File file = new File();
    > > public void modifyFile() {
    > > synchronize(sync) {
    > > // do modification of file
    > > }
    > > }

    >
    > > public String queryFile() {
    > > synchronize(sync) {
    > > return file.toString();
    > > }
    > > }
    > > }

    >
    > > Also be aware that Java 1.5 includes a new locking mechanism and other
    > > concurrency utilities which gives you more fine grained control over
    > > thread synchronization.
    > > <http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-
    > > summary.html>

    >
    > > Good luck :)

    >
    > Daniel:
    >
    > Thank you very much for your response but it doesn't really answer my
    > question. As to the immutable, I'm not muting. So let me set the
    > scenario again.
    >
    > Class with instance variable that is reference to Integer. One thread
    > makes new Integers and assigns them to the instance variable. The other
    > thread calls some method on the Integer. I want to know if making the
    > variable volatile will guarantee that the second thread always sees the
    > latest integer created by the first thread.
    >
    > I know that I can wrap both pieces of code in a synchronized block but I
    > want to understand my question.
    >
    > Thanks very much,
    >
    > --
    >
    > Knute Johnson
    > email s/nospam/knute/



    Ah, you didn't ask about volatile before. Yes, volatile is supposed
    to make it so that one thread can see the primative data written by
    another in a thread safe manor. A reference to an object is a
    primative for this argument.

    So, if all you care about is the reference, then you don't need
    synchronization. Although, you still might be better off looking into
    java.util.concurrent.AtomicInteger or
    java.util.concurrent.AtomicReference
    <http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-
    summary.html>

    Hope this answers your question a little better.
    Daniel Pitts, Jan 30, 2007
    #7
  8. On 2007-01-30, Knute Johnson <> wrote:
    > Thank you very much for your response but it doesn't really answer my
    > question. As to the immutable, I'm not muting. So let me set the
    > scenario again.
    >
    > Class with instance variable that is reference to Integer. One thread
    > makes new Integers and assigns them to the instance variable. The other
    > thread calls some method on the Integer. I want to know if making the
    > variable volatile will guarantee that the second thread always sees the
    > latest integer created by the first thread.


    No, volatile does not "guarantee that the second thread always sees the
    latest integer created by the first thread". What volatile guarantees
    is that when one thread executes assignment statements to volatile
    variables other threads will see the effect of the assignment
    statements in the same order that they were executed.

    It is possible that one thread starts executing an assignment statement
    to a volatile variable and very slightly later another thread starts
    executing a statement that uses the value of that variable. The second
    thread may get the value of the variable before latest assignment
    statment by the first thread. A basic problem is that without some
    form of synchronization between theads (not necessarily by the Java
    synchronize statement) there is no definite time ordering of operations
    between threads.
    A. Bolmarcich, Jan 30, 2007
    #8
  9. A. Bolmarcich wrote:
    > On 2007-01-30, Knute Johnson <> wrote:
    >> Thank you very much for your response but it doesn't really answer my
    >> question. As to the immutable, I'm not muting. So let me set the
    >> scenario again.
    >>
    >> Class with instance variable that is reference to Integer. One thread
    >> makes new Integers and assigns them to the instance variable. The other
    >> thread calls some method on the Integer. I want to know if making the
    >> variable volatile will guarantee that the second thread always sees the
    >> latest integer created by the first thread.

    >
    > No, volatile does not "guarantee that the second thread always sees the
    > latest integer created by the first thread". What volatile guarantees
    > is that when one thread executes assignment statements to volatile
    > variables other threads will see the effect of the assignment
    > statements in the same order that they were executed.
    >
    > It is possible that one thread starts executing an assignment statement
    > to a volatile variable and very slightly later another thread starts
    > executing a statement that uses the value of that variable. The second
    > thread may get the value of the variable before latest assignment
    > statment by the first thread. A basic problem is that without some
    > form of synchronization between theads (not necessarily by the Java
    > synchronize statement) there is no definite time ordering of operations
    > between threads.


    This is why I keep asking these questions because I get different
    answers. Can you explain what is meant in the documentation then by:

    JLS 17.4.4 Synchronization Order
    ....
    A write to a volatile variable (§8.3.1.4) v synchronizes-with all
    subsequent reads of v by any thread (where subsequent is defined
    according to the synchronization order).

    Thanks very much,

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 31, 2007
    #9
  10. On 2007-01-31, Knute Johnson <> wrote:
    > This is why I keep asking these questions because I get different
    > answers. Can you explain what is meant in the documentation then by:
    >
    > JLS 17.4.4 Synchronization Order
    > ...
    > A write to a volatile variable (§8.3.1.4) v synchronizes-with all
    > subsequent reads of v by any thread (where subsequent is defined
    > according to the synchronization order).


    Note that "subsequent is defined according to the synchronization order".
    Earlier in the section synchronization order is defined of an execution.
    Different executions may have different synchronization orders.

    According to the section 17.4.5 Happens-before Order: "It should be noted
    that the presence of a happens-before relationship between two actions
    does not necessarily imply that they have to take place in that order in
    an implementation. If the reordering produces results consistent with a
    legal execution, it is not illegal."

    If there is nothing that forces the ordering of an execution to be that
    the write action is before the read, then the read may occur before the
    write.

    Your previous question was: "I want to know if making the variable
    volatile will guarantee that the second thread always sees the latest
    integer created by the first thread." The answer depends on exactly
    what you mean by "latest". The second thread will always see the most
    recent write action by the first thread that has completed. However,
    unless you have another synchronization action to force what you
    consider to be the most recent write to be done before the read, the
    answer is no.
    A. Bolmarcich, Jan 31, 2007
    #10
  11. A. Bolmarcich wrote:
    > On 2007-01-31, Knute Johnson <> wrote:
    >> This is why I keep asking these questions because I get different
    >> answers. Can you explain what is meant in the documentation then by:
    >>
    >> JLS 17.4.4 Synchronization Order
    >> ...
    >> A write to a volatile variable (§8.3.1.4) v synchronizes-with all
    >> subsequent reads of v by any thread (where subsequent is defined
    >> according to the synchronization order).

    >
    > Note that "subsequent is defined according to the synchronization order".
    > Earlier in the section synchronization order is defined of an execution.
    > Different executions may have different synchronization orders.
    >
    > According to the section 17.4.5 Happens-before Order: "It should be noted
    > that the presence of a happens-before relationship between two actions
    > does not necessarily imply that they have to take place in that order in
    > an implementation. If the reordering produces results consistent with a
    > legal execution, it is not illegal."
    >
    > If there is nothing that forces the ordering of an execution to be that
    > the write action is before the read, then the read may occur before the
    > write.
    >
    > Your previous question was: "I want to know if making the variable
    > volatile will guarantee that the second thread always sees the latest
    > integer created by the first thread." The answer depends on exactly
    > what you mean by "latest". The second thread will always see the most
    > recent write action by the first thread that has completed. However,
    > unless you have another synchronization action to force what you
    > consider to be the most recent write to be done before the read, the
    > answer is no.


    Thanks very much for your response. The two actions are independent and
    I do not want to effect when they occur. I just want to ensure that if
    an assignment is made to the variable that any subsequent read in the
    other thread will have the latest value.

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 31, 2007
    #11
  12. On 2007-01-31, Knute Johnson <> wrote:
    > Thanks very much for your response. The two actions are independent and
    > I do not want to effect when they occur. I just want to ensure that if
    > an assignment is made to the variable that any subsequent read in the
    > other thread will have the latest value.


    Without any other sychronization action between the threads, the only
    way you know that a read was subsequent to a write is based on the value
    that was read. A read is subsequent to a write that wrote the value
    that was read.

    The fact that the variable is volatile means that reads and writes by
    a thread cannot be reordered to be before the previous synchronization
    action or after the next synchronization action. According to section
    "8.3.1.4 volatile Fields" of the JLS (from
    http://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
    given the class

    class Test {
    static volatile int i = 0, j = 0;
    static void one() { i++; j++; }
    static void two() {
    System.out.println("i=" + i + " j=" + j);
    }
    }

    If method one() is repeatedly called by one thread and method two() is
    repeatedly called by another thread, then according to the JLS:

    Therefore, the shared value for j is never greater than that for i,
    because each update to i must be reflected in the shared value for i
    before the update to j occurs.

    If the variables i and j were not volatile, then lines printed by method
    two() may have a value of j greater than that of i.
    A. Bolmarcich, Jan 31, 2007
    #12
  13. A. Bolmarcich wrote:
    > On 2007-01-31, Knute Johnson <> wrote:
    >> Thanks very much for your response. The two actions are independent and
    >> I do not want to effect when they occur. I just want to ensure that if
    >> an assignment is made to the variable that any subsequent read in the
    >> other thread will have the latest value.

    >
    > Without any other sychronization action between the threads, the only
    > way you know that a read was subsequent to a write is based on the value
    > that was read. A read is subsequent to a write that wrote the value
    > that was read.
    >
    > The fact that the variable is volatile means that reads and writes by
    > a thread cannot be reordered to be before the previous synchronization
    > action or after the next synchronization action. According to section
    > "8.3.1.4 volatile Fields" of the JLS (from
    > http://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
    > given the class
    >
    > class Test {
    > static volatile int i = 0, j = 0;
    > static void one() { i++; j++; }
    > static void two() {
    > System.out.println("i=" + i + " j=" + j);
    > }
    > }
    >
    > If method one() is repeatedly called by one thread and method two() is
    > repeatedly called by another thread, then according to the JLS:
    >
    > Therefore, the shared value for j is never greater than that for i,
    > because each update to i must be reflected in the shared value for i
    > before the update to j occurs.
    >
    > If the variables i and j were not volatile, then lines printed by method
    > two() may have a value of j greater than that of i.


    So that's a yes?

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 31, 2007
    #13
  14. Knute Johnson

    Daniel Pitts Guest

    On Jan 31, 11:40 am, "A. Bolmarcich" <9.net>
    wrote:
    > On 2007-01-31, Knute Johnson <> wrote:
    >
    > > Thanks very much for your response. The two actions are independent and
    > > I do not want to effect when they occur. I just want to ensure that if
    > > an assignment is made to the variable that any subsequent read in the
    > > other thread will have the latest value.

    >
    > Without any other sychronization action between the threads, the only
    > way you know that a read was subsequent to a write is based on the value
    > that was read. A read is subsequent to a write that wrote the value
    > that was read.
    >
    > The fact that the variable is volatile means that reads and writes by
    > a thread cannot be reordered to be before the previous synchronization
    > action or after the next synchronization action. According to section
    > "8.3.1.4 volatile Fields" of the JLS (fromhttp://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
    > given the class
    >
    > class Test {
    > static volatile int i = 0, j = 0;
    > static void one() { i++; j++; }
    > static void two() {
    > System.out.println("i=" + i + " j=" + j);
    > }
    > }
    >
    > If method one() is repeatedly called by one thread and method two() is
    > repeatedly called by another thread, then according to the JLS:
    >
    > Therefore, the shared value for j is never greater than that for i,
    > because each update to i must be reflected in the shared value for i
    > before the update to j occurs.
    >
    > If the variables i and j were not volatile, then lines printed by method
    > two() may have a value of j greater than that of i.

    Actually, they still might.
    imagine this scenario:

    Thread 2: two gets called
    Thread 2: value i is loaded and converted to a string for
    concatication
    Thread 1: one gets called
    Thread 1: one gets called again
    Thread 1: one gets called a third time
    Thread 2: continues with j

    Output is i=0 j=3

    Also possible is:
    Thread 1: one gets called
    Thread 1: increments i
    Thread 2: one gets called
    Thread 2: increments i
    Thread 3: two gets called
    Thread 3: output i=2 j=0
    Thread1: increments j
    Thread2: increments j


    A even worse possibility:
    Thread 1: reads value of i
    Thread 2: reads value of i
    Thread 1: writes value of i+1 back to i
    Thread 2: writes values of i+1 back to i
    Thread 1: increments j
    Thread 2: increments j
    Thread 3: wait for thread1 and thread2
    Thread 3: call two
    Output i=1 j=2
    Daniel Pitts, Jan 31, 2007
    #14
  15. On 2007-01-31, Knute Johnson <> wrote:
    > A. Bolmarcich wrote:
    >> On 2007-01-31, Knute Johnson <> wrote:
    >>> Thanks very much for your response. The two actions are independent and
    >>> I do not want to effect when they occur. I just want to ensure that if
    >>> an assignment is made to the variable that any subsequent read in the
    >>> other thread will have the latest value.

    >>
    >> Without any other sychronization action between the threads, the only
    >> way you know that a read was subsequent to a write is based on the value
    >> that was read. A read is subsequent to a write that wrote the value
    >> that was read.
    >>
    >> The fact that the variable is volatile means that reads and writes by
    >> a thread cannot be reordered to be before the previous synchronization
    >> action or after the next synchronization action. According to section
    >> "8.3.1.4 volatile Fields" of the JLS (from
    >> http://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
    >> given the class
    >>
    >> class Test {
    >> static volatile int i = 0, j = 0;
    >> static void one() { i++; j++; }
    >> static void two() {
    >> System.out.println("i=" + i + " j=" + j);
    >> }
    >> }
    >>
    >> If method one() is repeatedly called by one thread and method two() is
    >> repeatedly called by another thread, then according to the JLS:
    >>
    >> Therefore, the shared value for j is never greater than that for i,
    >> because each update to i must be reflected in the shared value for i
    >> before the update to j occurs.
    >>
    >> If the variables i and j were not volatile, then lines printed by method
    >> two() may have a value of j greater than that of i.

    >
    > So that's a yes?


    Like many questions about the interaction of multiple threads, the
    question does not have a simple "yes" or "no" answer. The best that I
    can respond is to repeat: a read is subsequent to a write that wrote the
    value that was read. If that is what you mean by "subsequent read" in
    your qestion, the answer is "yes".
    A. Bolmarcich, Feb 1, 2007
    #15
  16. On 2007-01-31, Daniel Pitts <> wrote:
    > On Jan 31, 11:40 am, "A. Bolmarcich" <9.net>
    > wrote:
    >> On 2007-01-31, Knute Johnson <> wrote:
    >>
    >> > Thanks very much for your response. The two actions are independent and
    >> > I do not want to effect when they occur. I just want to ensure that if
    >> > an assignment is made to the variable that any subsequent read in the
    >> > other thread will have the latest value.

    >>
    >> Without any other sychronization action between the threads, the only
    >> way you know that a read was subsequent to a write is based on the value
    >> that was read. A read is subsequent to a write that wrote the value
    >> that was read.
    >>
    >> The fact that the variable is volatile means that reads and writes by
    >> a thread cannot be reordered to be before the previous synchronization
    >> action or after the next synchronization action. According to section
    >> "8.3.1.4 volatile Fields" of the JLS (fromhttp://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
    >> given the class
    >>
    >> class Test {
    >> static volatile int i = 0, j = 0;
    >> static void one() { i++; j++; }
    >> static void two() {
    >> System.out.println("i=" + i + " j=" + j);
    >> }
    >> }
    >>
    >> If method one() is repeatedly called by one thread and method two() is
    >> repeatedly called by another thread, then according to the JLS:
    >>
    >> Therefore, the shared value for j is never greater than that for i,
    >> because each update to i must be reflected in the shared value for i
    >> before the update to j occurs.
    >>
    >> If the variables i and j were not volatile, then lines printed by method
    >> two() may have a value of j greater than that of i.

    > Actually, they still might.
    > imagine this scenario:
    >
    > Thread 2: two gets called
    > Thread 2: value i is loaded and converted to a string for
    > concatication
    > Thread 1: one gets called
    > Thread 1: one gets called again
    > Thread 1: one gets called a third time
    > Thread 2: continues with j
    >
    > Output is i=0 j=3


    Which is a case of the value of j being greater than that of i that I wrote
    may occur.

    > Also possible is:
    > Thread 1: one gets called
    > Thread 1: increments i
    > Thread 2: one gets called
    > Thread 2: increments i
    > Thread 3: two gets called
    > Thread 3: output i=2 j=0
    > Thread1: increments j
    > Thread2: increments j


    In the extract of the JLS section, there are only two threads: one invokes
    one() and the other invokes two().

    > A even worse possibility:
    > Thread 1: reads value of i
    > Thread 2: reads value of i
    > Thread 1: writes value of i+1 back to i
    > Thread 2: writes values of i+1 back to i
    > Thread 1: increments j
    > Thread 2: increments j
    > Thread 3: wait for thread1 and thread2
    > Thread 3: call two
    > Output i=1 j=2


    In the extract of the JLS section, there are only two threads: one invokes
    one() and the other invokes two().
    A. Bolmarcich, Feb 1, 2007
    #16
  17. Knute Johnson

    Daniel Pitts Guest

    On Jan 31, 4:24 pm, "A. Bolmarcich" <9.net>
    wrote:
    > On 2007-01-31, Daniel Pitts <> wrote:
    > > On Jan 31, 11:40 am, "A. Bolmarcich" <9.net>
    > > wrote:

    [snip]
    > >> The fact that the variable is volatile means that reads and writes by
    > >> a thread cannot be reordered to be before the previous synchronization
    > >> action or after the next synchronization action. According to section
    > >> "8.3.1.4 volatile Fields" of the JLS (fromhttp://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
    > >> given the class

    >
    > >> class Test {
    > >> static volatile int i = 0, j = 0;
    > >> static void one() { i++; j++; }
    > >> static void two() {
    > >> System.out.println("i=" + i + " j=" + j);
    > >> }
    > >> }

    >
    > >> If method one() is repeatedly called by one thread and method two() is
    > >> repeatedly called by another thread, then according to the JLS:

    >
    > >> Therefore, the shared value for j is never greater than that for i,
    > >> because each update to i must be reflected in the shared value for i
    > >> before the update to j occurs.

    >
    > >> If the variables i and j were not volatile, then lines printed by method
    > >> two() may have a value of j greater than that of i.

    > > Actually, they still might.
    > > imagine this scenario:

    >
    > > Thread 2: two gets called
    > > Thread 2: value i is loaded and converted to a string for
    > > concatication
    > > Thread 1: one gets called
    > > Thread 1: one gets called again
    > > Thread 1: one gets called a third time
    > > Thread 2: continues with j

    >
    > > Output is i=0 j=3

    >
    > Which is a case of the value of j being greater than that of i that I wrote
    > may occur.

    You wrote:
    > If the variables i and j were not volatile, then lines printed by method
    > two() may have a value of j greater than that of i.


    My example is allowing them to be volatile.
    Actually, my example is valid for both volatile and non-volatile
    variables.

    With two threads repeatedly calling their respective methods, you can
    get a situation with i > j or j > i, regardless of the volatility of
    the variables.

    Therefore, your post doesn't explain volatile at all.
    Daniel Pitts, Feb 1, 2007
    #17
  18. A. Bolmarcich wrote:
    > On 2007-01-31, Knute Johnson <> wrote:
    >> A. Bolmarcich wrote:
    >>> On 2007-01-31, Knute Johnson <> wrote:
    >>>> Thanks very much for your response. The two actions are independent and
    >>>> I do not want to effect when they occur. I just want to ensure that if
    >>>> an assignment is made to the variable that any subsequent read in the
    >>>> other thread will have the latest value.
    >>> Without any other sychronization action between the threads, the only
    >>> way you know that a read was subsequent to a write is based on the value
    >>> that was read. A read is subsequent to a write that wrote the value
    >>> that was read.
    >>>
    >>> The fact that the variable is volatile means that reads and writes by
    >>> a thread cannot be reordered to be before the previous synchronization
    >>> action or after the next synchronization action. According to section
    >>> "8.3.1.4 volatile Fields" of the JLS (from
    >>> http://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
    >>> given the class
    >>>
    >>> class Test {
    >>> static volatile int i = 0, j = 0;
    >>> static void one() { i++; j++; }
    >>> static void two() {
    >>> System.out.println("i=" + i + " j=" + j);
    >>> }
    >>> }
    >>>
    >>> If method one() is repeatedly called by one thread and method two() is
    >>> repeatedly called by another thread, then according to the JLS:
    >>>
    >>> Therefore, the shared value for j is never greater than that for i,
    >>> because each update to i must be reflected in the shared value for i
    >>> before the update to j occurs.
    >>>
    >>> If the variables i and j were not volatile, then lines printed by method
    >>> two() may have a value of j greater than that of i.

    >> So that's a yes?

    >
    > Like many questions about the interaction of multiple threads, the
    > question does not have a simple "yes" or "no" answer. The best that I
    > can respond is to repeat: a read is subsequent to a write that wrote the
    > value that was read. If that is what you mean by "subsequent read" in
    > your qestion, the answer is "yes".


    I have no idea what that means. By subsequent I mean the usual meaning
    that the subsequent action occurs later in time than the precedent
    action. So in the case I am asking about, the first thread writes to
    the variable and then some time later the second thread reads the variable.

    Does volatile guarantee that the second thread will see the value
    written by the first thread?

    Does synchronizing guarantee that the second thread will see the value
    written by the first thread?

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Feb 1, 2007
    #18
  19. On 2007-02-01, Knute Johnson <> wrote:
    > A. Bolmarcich wrote:
    >> Like many questions about the interaction of multiple threads, the
    >> question does not have a simple "yes" or "no" answer. The best that I
    >> can respond is to repeat: a read is subsequent to a write that wrote the
    >> value that was read. If that is what you mean by "subsequent read" in
    >> your qestion, the answer is "yes".

    >
    > I have no idea what that means. By subsequent I mean the usual meaning
    > that the subsequent action occurs later in time than the precedent
    > action. So in the case I am asking about, the first thread writes to
    > the variable and then some time later the second thread reads the variable.
    >
    > Does volatile guarantee that the second thread will see the value
    > written by the first thread?
    >
    > Does synchronizing guarantee that the second thread will see the value
    > written by the first thread?


    When "the first thread writes to the variable" a processor requests that
    a value be written to a memory address. On some computers the request
    goes into a queue and the effect of the memory write is visible to other
    threads sometime later. While the memory write is being done, the first
    thread continues executing.

    On this type of computer architecture, whether a memory read is subsequent
    to a memory write depends on the whether the read gets the value written
    by the memory write. It does not depend on the global order in which
    threads execute instructions.

    The answer to your question: "Does volatile guarantee that the second
    thread will see the value written by the first thread?", is yes, as long
    as you take "some time later" being in terms of what is visible in memory
    and not in terms of the global order in which the threads execute the
    instruction.

    The answer to your question: "Does synchronizing guarantee that the
    second thread will see the value written by the first thread?" is yes,
    with "some time later" being in terms of the second thread entering its
    synchronized block after the first thread exited its synchronized block.
    A. Bolmarcich, Feb 1, 2007
    #19
  20. On 2007-02-01, Daniel Pitts <> wrote:
    > On Jan 31, 4:24 pm, "A. Bolmarcich" <9.net>
    > wrote:
    >> On 2007-01-31, Daniel Pitts <> wrote:

    [snip]
    >> > imagine this scenario:

    >>
    >> > Thread 2: two gets called
    >> > Thread 2: value i is loaded and converted to a string for
    >> > concatication
    >> > Thread 1: one gets called
    >> > Thread 1: one gets called again
    >> > Thread 1: one gets called a third time
    >> > Thread 2: continues with j

    >>
    >> > Output is i=0 j=3

    >>
    >> Which is a case of the value of j being greater than that of i that I wrote
    >> may occur.

    > You wrote:
    >> If the variables i and j were not volatile, then lines printed by method
    >> two() may have a value of j greater than that of i.

    >
    > My example is allowing them to be volatile.
    > Actually, my example is valid for both volatile and non-volatile
    > variables.
    >
    > With two threads repeatedly calling their respective methods, you can
    > get a situation with i > j or j > i, regardless of the volatility of
    > the variables.


    Sorry, I did not read your scenario carefully enough. Yes, when
    i and j are volatile, if two() reads the value of i and one() is invoked
    again before two() reads the value of j, then two() may print j value
    that is greater than the i value.
    A. Bolmarcich, Feb 1, 2007
    #20
    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. chlori

    Two more questions

    chlori, Jan 20, 2005, in forum: HTML
    Replies:
    6
    Views:
    445
    Spartanicus
    Jan 21, 2005
  2. Michael
    Replies:
    4
    Views:
    392
    Matt Hammond
    Jun 26, 2006
  3. GenxLogic
    Replies:
    3
    Views:
    1,227
    andrewmcdonagh
    Dec 6, 2006
  4. Robert Klemme

    With a Ruby Yell: more, more more!

    Robert Klemme, Sep 28, 2005, in forum: Ruby
    Replies:
    5
    Views:
    196
    Jeff Wood
    Sep 29, 2005
  5. Robert Wallace

    substitute two ore more with two or more

    Robert Wallace, Dec 31, 2003, in forum: Perl Misc
    Replies:
    1
    Views:
    93
    Big and Blue
    Dec 31, 2003
Loading...

Share This Page