title: Would a thread handling a subsequent network request be guaranteed to see the value of a volatile variable written during a previous request?
body: <p>I have this theoretical question about the Java Memory Model. Suppose I have a server with these two request handlers in the following class:</p>
  
  <pre><code>class MyHandlers {
    volatile int someFlag = 0;
  
    String handleFirstRequest() {
      someFlag = 1;
      return "Hello!";
    }
  
    String handleSecondRequest() {
      return "value of someFlag: " + someFlag;
    }
  }
  </code></pre>
  
  <p>I also have a client. My client sends a network request that triggers executing handleFirstRequest. The client waits until the request completes. Once the first request completes, the client sends the second request that triggers handleSecondRequest.</p>
  
  <p><strong>Question:</strong> How does the Java Memory Model prevent the response to the second request from being <code>"value of someFlag: 0"</code>?</p>
  
  <p>Notes: I understand that, in practice, the thread handling the second response will always see <code>someFlag</code> as 1.</p>
  
  <p>If I read the JMM correctly, there is a synchronization order that is a total order, which would order the volatile read and the volatile write (<code>someFlag = 1</code>) in my example. If the read is subsequent to the write, then the read will see the write. Is it possible to have a case where the write is subsequent to the read? In this case, the write does not synchronizes-with the read, and there would be no happens-before relationship between the write and the read. This would lead the thread handling the second request to see <code>someFlag</code> as 0. Where does my understanding go wrong?</p>
  
  <p><strong>Additional thoughts (2020 Mar 2):</strong> The JMM does not refer to the concept of time. Synchronization actions are ordered according to synchronization order, but nothing in the JMM says that synchronization order is the same as order of actions sorted by time. This suggests a Java implementation may order the read of <code>someFlag</code> <strong>before</strong> the write even though the read occurred <strong>after</strong> the write according to the clock. It seems like the JMM only guarantees that <strong>if</strong> the volatile read is ordered after the volatile write, then writes before the volatile write are visible to reads after the volatile read.</p>