Seriously? ++ is done by one thread *only*. concurrency is not important here. Generally only one thread writes.

See chapter 16 of Java Concurrency in Practice.

(Why not just use an AtomicInteger#getAndIncrement()?)

What I was trying to say was that writes to non-volatile variables by thread 1 cannot be reordered past a write to a volatile variable by thread 1 and a read by a volatile variable by thread 2, thread 2 will see all the writes by thread 1.

If you have this structure, there is no race condition for the non-volatile data.

thread1:
1a) write to non-volatile variable A
1b) write to non-volatile variable B
1c) write to volatile variable C

thread2:
2a) read from volatile variable C
2b) read from non-volatile variable A
2c) read from non-volatile variable B

1a and 1b can be permuted, and 2b and 2c can be permuted, but 1a and 1b can’t be moved past 1c, and 2b and 2c can’t be moved ahead of 2a.

That means that you can use volatiles to implement locks:

“The third of these rules [Volatile rule. A write to a volatile field happens before every subsequent read of the same volatile.], the one governing volatile fields, is a stronger guarantee than that made by the original memory model. This is useful because now volatile variables can be used as ‘guard’ variables — you can now use a volatile field to indicate across threads that some set of actions has been performed, and be confident that those actions will be visible to all other threads.”

(Brian Goetz in “JSR 133 in Public Review”, http://today.java.net/lpt/a/84 )

I’m sorry I didn’t make this clear.

Sorry, that isn’t right. If you have several operations in two threads, they will still be competing unless there’s a lock.

I don’t really see where do I imply that. Race conditions and synchronization just wasn’t relevant to my very specific problem.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.1701

Wow, thanks! That is exactly what I was looking for!

http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile

“Under the new memory model, it is still true that volatile variables cannot be reordered with each other. The difference is that it is now no longer so easy to reorder normal field accesses around them. Writing to a volatile field has the same memory effect as a monitor release, and reading from a volatile field has the same memory effect as a monitor acquire. In effect, because the new memory model places stricter constraints on reordering of volatile field accesses with other field accesses, volatile or not, anything that was visible to thread A when it writes to volatile field f becomes visible to thread B when it reads f.”

The source code in there is basically the same that you have.