Re: AtomicReferenceArray writes and visibility

On 3/30/11 10:43 PM, Volker Borchert wrote:


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.


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