In Java only ready flag has to be declared volatile, data can be plain int.
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile

[edit] Correction, after a long exchange with experts, and giving up on Java-specific proof techniques, I am convinced now that both Anthony and Dmitriy were right. I’ll try to explain it in my next post.

In summary, Dmitriy’s implementation is correct, yours is broken. The key is that he uses exchange on turn (_victim), whereas you use exchange on _interested[me] and a plain store on _victim. You need the store to _victim to be an exchange in order for everything to be guaranteed.

In general, however, you can’t make assumption about how atomic operations translate into fences or locked instructions when you don’t know the underlying architecture. The only guarantees you have are, as you mentioned, the semantics of atomics in terms of happens-before and synchronizes-with relations. Notice however that very few people frame their arguments in those terms.

The obvious rules of discussing algorithms written in terms of atomics are: (1) it’s enough to show that it doesn’t work on one processor to prove its incorrectness, and (2) to prove its correctness you can’t use any processor-specific arguments. Of course that’s much harder!

So even though I don’t have a formal proof, I believe my implementation of Peterson lock is correct. For all I know, Dmitriy’s implementation might also be correct, but it’s much harder to prove.

That’s not true. Your code above need not have *any* fences on an x86, because the exchange is an XCHG instruction, which is serializing. See my post about the C++0x memory model on x86 CPUs. http://www.justsoftwaresolutions.co.uk/threading/intel-memory-ordering-and-c++-memory-model.html

On some architectures, memory_order_acq_rel will require a fence both before AND after the instruction (possibly of different sorts).

> But the Standard never specifies where the fences go, so I can’t rely on it in my implementation.

The Standard doesn’t specify the implementation details, that is true. It does however specify the required ordering constraints in terms of relationships called “happens-before” and “synchronizes-with”.

Incidentally, if you feel that you can reason better with fences, you could write them explicitly: use memory_order_relaxed for all the loads and stores and then use explicit atomic_thread_fence() calls to put the fences in.