Results 1 to 3 of 3
  1. #1
    gib65 is offline Member
    Join Date
    Jun 2010
    Posts
    86
    Rep Power
    0

    Default question about so-called "memory consistency errors"

    Hello,

    I'm new to java threads and synchronization. I'm going through a tutorial here and I'm confused about what it says here.

    It says:

    Suppose a simple int field is defined and initialized:

    int counter = 0;

    The counter field is shared between two threads, A and B. Suppose thread A increments counter:
    counter++;

    Then, shortly afterwards, thread B prints out counter:
    System.out.println(counter);

    If the two statements had been executed in the same thread, it would be safe to assume that the value printed out would be "1". But if the two statements are executed in separate threads, the value printed out might well be "0", because there's no guarantee that thread A's change to counter will be visible to thread B

    I'm not sure why counter would still be 0 after thread A has incremented it. Isn't it just one variable? If thread A increments it, it becomes 1, and every other thread (or object, or any part of the program) should see the value 1 stored there when it tries to access it... no? It seems pretty clear from the wording that thread B prints out the value of counter "shortly afterwards" meaning that the increment and the printing aren't executed exactly at the same time, so the increment should be done before the printing starts. The only way to make sense of this, to me, is to assume that each thread gets its own copy of counter... is that what's going on? Or maybe I just need to understand what "visible" means.

  2. #2
    j2me64's Avatar
    j2me64 is offline Senior Member
    Join Date
    Sep 2009
    Location
    Zurich, Switzerland
    Posts
    962
    Rep Power
    5

    Default

    Quote Originally Posted by gib65 View Post
    I'm not sure why counter would still be 0 after thread A has incremented it. Isn't it just one variable? If thread A increments it, it becomes 1, and every other thread (or object, or any part of the program) should see the value 1 stored there when it tries to access it... no?

    no. even if you type

    Thread1.start();
    Thread2.start();

    there is no guarantee, that Thread1 starts before Thread2. so if Thread2 reads c, its content will be 0.


    Quote Originally Posted by gib65 View Post
    The only way to make sense of this, to me, is to assume that each thread gets its own copy of counter...

    yes, but: when you have to create objects in java, sometimes you have the real situation, that two object have to share the same object. assume there are a producer and a consumer that use the same store. or you and your partner use the same bank account. if you have to implement this objects, then use the keyword synchronized for your methods. the sun-site says


    * First, it is not possible for two invocations of synchronized methods on the same object to interleave. When one thread is executing a synchronized method for an object, all other threads that invoke synchronized methods for the same object block (suspend execution) until the first thread is done with the object.
    * Second, when a synchronized method exits, it automatically establishes a happens-before relationship with any subsequent invocation of a synchronized method for the same object. This guarantees that changes to the state of the object are visible to all threads.
    Last edited by j2me64; 06-19-2010 at 11:48 AM.

  3. #3
    gib65 is offline Member
    Join Date
    Jun 2010
    Posts
    86
    Rep Power
    0

Similar Threads

  1. Replies: 6
    Last Post: 06-11-2010, 07:03 PM
  2. "Cannot find symbol" errors in Java
    By 23Zone in forum New To Java
    Replies: 1
    Last Post: 02-17-2010, 07:13 AM
  3. Replies: 1
    Last Post: 01-21-2010, 09:20 AM
  4. Replies: 2
    Last Post: 01-24-2009, 06:56 PM
  5. Replies: 1
    Last Post: 10-20-2008, 07:35 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •