Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #2638

Re: AtomicReferenceArray writes and visibility

Show all headers | View raw

On 3/30/11 10:43 PM, Volker Borchert wrote:
> Hello all,
>
> reading on the "new" memory model and AtomicReferenceArray, it
> seems that anything done before a .set() on an AtomicReferenceArray
> "happens-before" anything done after a .get() on the same
> AtomicReferenceArray.
>
> Two questions:
>
> 1. Am I right?

Essentially, but not literally.  You need to qualify your statement to 
specify that the action that occurs before the write (the call to set()) 
has to be in the same thread as the write, and the action that occurs 
after the read (the call to get()) has to be in the same thread as the read.

Only with that requirement can you be sure that all of the following are 
true:

   • in a given thread, action x occurs before action s, the write
   • in a given thread, action r, the read, occurs before action y
   • action s is synchronized with action r, where r follows s
   • and thus, one can conclude that x happens-before y.

If x occurred in a different thread from s or y occurred in a different 
thread from r, then we'd have no assurance that x happens-before s, or 
that r happens-before y.

> 2. If so, does this hold true if the write does not actually change
>     the value, in other words, if the write only "refreshes" the
>     memory location?

Yes, sort of.  The memory model doesn't care whether the value changed, 
simply that some synchronization was done.

However, note that it would not be possible for your program to know 
whether it was operating under that guarantee or not.  The 
synchronization between s and r (see above) simply resolves a race 
condition between those two actions.  If r wins the race, then the code 
executing y would be observing the old value, and not have any way to be 
assured that x had already happened.

In other words, suppose I've got the following:

   int a = 0;
   bool f = true;
   object o = new Object();

   thread 1                   thread 2
   ----------                 ----------
   a = 1;
   synchronized (o)
   {
     f = true;
   }
                              synchronized (o)
                              {
                                if (f)
                                {
                                  System.out.println(a);
                                }
                              }

There's no way to tell the difference between that and:

   thread 1                   thread 2
   ----------                 ----------
                              synchronized (o)
                              {
                                if (f)
                                {
                                  System.out.println(a);
                                }
                              }
   a = 1;
   synchronized (o)
   {
     f = true;
   }

So, sure.  The memory model assures us that in the first example, the 
output is 1.  But the program has no way to know that it's not operating 
in the sequence seen in the second example.  The output just as easily 
could be 0, in spite of the synchronization of f.

For that matter, even with f being written after it's read, as in the 
second example, a could still have been set before the read, and the 
output would still be 1 in that case, as in the first example, but with 
a different order of the write and read.  The bottom line is that if the 
synchronized value doesn't change, the problem doesn't really have any 
way to know what the actual sequence of execution was.

To take advantage of the rules, the variable being synchronized has to 
be modified in some meaningful way, such that the code can tell what's 
important.

Note that all of this isn't unique to AtomicReferenceArray.  It applies 
to any synchronized access to a given variable.  See JLS 17.4.5 for the 
specifics.

Pete

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

AtomicReferenceArray writes and visibility v_borchert@despammed.com (Volker Borchert) - 2011-03-31 05:43 +0000
  Re: AtomicReferenceArray writes and visibility Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-03-31 00:52 -0700
    Re: AtomicReferenceArray writes and visibility v_borchert@despammed.com (Volker Borchert) - 2011-04-02 06:28 +0000
  Re: AtomicReferenceArray writes and visibility Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2011-03-31 20:55 -0700
  Re: AtomicReferenceArray writes and visibility markspace <-@.> - 2011-03-31 21:22 -0700
    Re: AtomicReferenceArray writes and visibility Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-03-31 21:54 -0700
      Re: AtomicReferenceArray writes and visibility markspace <-@.> - 2011-03-31 21:58 -0700
        Re: AtomicReferenceArray writes and visibility Patricia Shanahan <pats@acm.org> - 2011-03-31 22:24 -0700
          Re: AtomicReferenceArray writes and visibility markspace <-@.> - 2011-03-31 22:55 -0700
  Re: AtomicReferenceArray writes and visibility Lew <lew@lewscanon.com> - 2011-04-01 11:40 -0700

csiph-web