title: Java concurrent visibility of primitive array writes
body: <p>I recently found this gem in my code base:</p>
  <pre><code>/** This class is used to &quot;publish&quot; changes to a non-volatile variable.
   *
   * Access to non-volatile and volatile variables cannot be reordered,
   * so if you make changes to a non-volatile variable before calling publish,
   * they are guaranteed to be visible to a thread which calls syncChanges
   *
   */
  private static class Publisher {
      //This variable may not look like it's doing anything, but it really is.
      //See the documentaion for this class.
      private volatile AtomicInteger sync = new AtomicInteger(0);
  
      void publish() {
          sync.incrementAndGet();
      }
  
      /**
       *
       * @return the return value of this function has no meaning.
       * You should not make *any* assumptions about it.
       */
      int syncChanges() {
          return sync.get();
      }
  }
  </code></pre>
  <p>This is used as such:</p>
  <p>Thread 1</p>
  <pre><code>float[][] matrix;
  matrix[x][y] = n;
  publisher.publish();
  </code></pre>
  <p>Thread 2</p>
  <pre><code>publisher.syncChanges();
  myVar = matrix[x][y];
  </code></pre>
  <p>Thread 1 is a background updating thread that runs continuously.  Thread 2 is a HTTP worker thread that does not care that what it reads is in any way consistent or atomic, only that the writes &quot;eventually&quot; get there and are not lost as offerings to the concurrency gods.</p>
  <p>Now, this triggers all my warning bells.  Custom concurrency algorithm written deep inside of unrelated code.</p>
  <p>Unfortunately, fixing the code is not trivial.  The Java support for concurrent primitive matrices is not good.  It looks like the clearest way to fix this is using a <code>ReadWriteLock</code>, but that would probably have negative performance implications.  Correctness is more important, clearly, but it seems like I should prove that this is <em>not</em> correct before just ripping it out of a performance sensitive area.</p>
  <p>According to <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility" rel="noreferrer">the java.util.concurrent documentation</a>, the following create <code>happens-before</code> relationships:</p>
  <blockquote>
  <p>Each action in a thread happens-before every action in that thread that comes later in the program's order.</p>
  <p>A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking.</p>
  </blockquote>
  <p>So it sounds like:</p>
  <ul>
  <li>matrix write happens-before publish() (rule 1)</li>
  <li>publish() happens-before syncChanges() (rule 2)</li>
  <li>syncChanges() happens-before matrix read (rule 1)</li>
  </ul>
  <p>So the code indeed has established a happens-before chain for the matrix.</p>
  <p>But I'm not convinced.  Concurrency is hard, and I'm not a domain expert.
  What have I missed?  Is this indeed safe?</p>