Read-write ordering - causality casualty :)

Question

hello,
{color:lightgray}my name is gnat and I am threadaholic{color}
I'm trying to figure if particular reordering of reads and writes is possible or not. The code snippet looks about as follows:
class Test {
    private static final int ORIGINAL = 0, UPDATED = 1;
    private int data1 = ORIGINAL, data2 = ORIGINAL;
    private void write() {
        data1 = UPDATED; // first write
        data2 = UPDATED; // second write
    private void read() {
        int secondWritten = data2; // first read
        int firstWritten = data1; // second read
        if (firstWritten == UPDATED)
            return; // first is already written
        if (secondWritten == ORIGINAL)
            return; // second is not yet written
        // we get to this point if:
        //   - first is not yet written and...
        //   - ...and second is already written
        System.out.println("new order");
        System.exit(0); // end of test
    public void execute() {
        Thread writerThread = new Thread() { public void run() { write(); } };
        Thread readerThread = new Thread() { public void run() { read(); } };
        writerThread.start();
        readerThread.start();
        try { writerThread.join(); }
        catch (InterruptedException ie) {/*swallow*/}
        try { readerThread.join(); }
        catch (InterruptedException ie) {/*swallow*/}
    public static void main(String[] args) {
        System.out.println("test started");
        while (true) { new Test().execute(); }
}At first, I felt like the reordering operations in write() method above is possible and that it will be quite easy to demonstrate in the execution of above code - with +"new order"+ in the output.
To my surprise, it turned out a bit more complicated. Execution never ended with +"new order"+ (I tried it with java 1.6.0_13 on XP/Pentium and Vista/AMD mashines). I tried some modifications of the code - it didn't help either.
At about that point, I decided to dive into JLS and other docs to find out if there's some guidance to find out whether reordering here is possible or not. I think I found the solution but I'm not quite sure - please help me to figure that.
Here is what I've got so far:
{color:purple}- "new order" can appear in the output if assignments in write are reordered and thread switch occurs in between these operations.
- Such a reordering is possible because it is (1) allowed per volatile specification and (2) does not violate causality requirements in [JLS 17.4.8|http://java.sun.com/docs/books/jls/third_edition/html/memory.html#62065|'...Causality Requirements'].
(1) In The [JSR-133 Cookbook for Compiler Writers|http://g.oswego.edu/dl/jmm/cookbook.html|'unofficial guide to implementing JMM'], "Can Reorder" table shows that Volatile Store can be reordered with Normal Store, which is the case in question code.
(2) Reordering in question code is conformant with causality requirements ([explained here|http://jeremymanson.blogspot.com/2007/08/causality-and-java-memory-model.html|'Causality and the JMM']) because read does not modify class fileds that are being assigned only within write.{color}
Is above reasoning correct?
I feel especially shaky about part (2) - causality. JLS 17.4.8 is quite complicated and I haven't grokked it yet.

Answer 1

...i think the write of data2 is allowed to happen before the write of data1 without violating volatile constraints. however, i suspect that this is highly unlikely in reality. i would imagine that most jit implementation will treat volatile interactions as barriers such that no reordering will occur around them, even if some is allowed.a-ha... that moves my puzzle closer to completion.
Indeed, it looks quite possible (and perfectly legal) for jit to be implemented that way.
And in case of such jit, write reordering will never happen - not because it's forbidden by JLS but because jit just does not use it - right?
Hm I suspected something like that. And, you know, that bumped me into causality stuff. I mean, assuming that err experimental investigation can be blocked by particular jit specifics, I decided to proceed with spec analysis. Here, I found that for my case there are volatile and causality requirements. So...
...I checked volatile spec - it was OK on reordering. Then, I proceeded into causality... and got kinda stuck there.
>
(2) Reordering in question code is conformant with causality requirements (explained here) because read does not modify class fileds that are being assigned only within write.Again, i don't quite agree with this. modifications by "read" would not affect the interactions between the "read" and "write" threads. the writes in the "write" thread could be reordered because volatile writes require all previous writes to happen, but do not have any requirements on subsequent writes. the reads in the "read" thread could be reordered because volatile reads require all subsequent reads to get fresh data but do not haave any requirements on previous reads.I think I understand. Your reasoning for allowed reordering in read makes sense.
But (probably my explanation in (2) is not clear on that) thing is, order within read doesn't really matter for my purpose. To get to "new order" output, something like this should occur:
-- (side note) code:sql tag makes suitable formatting for stuff like that :)
  0. initialization: data1 = ORIGINAL, data2 = ORIGINAL
  1. writerThread: data2 = UPDATED;
-- thread switch --
  2 (or 3). reader thread: secondWritten = data2; (reads UPDATED - "new order" needs this)
  3 (or 2). reader thread: firstWritten = data1; (reads ORIGINAL - "new order" needs this)
-- at this point, I don't care anymore since "new order" is achieved
-- thread switch --
  4. writerThread: data2 = UPDATED; (doesn't matter for "new order")
{code}
You see - reads at steps 2 and 3 above are interchangeable without affecting desired result. That's why I didn't worry about any ordering within read. Does that make sense?