Question about thread-safe access to Entry instances

[wickedrob]

The Disruptor design and code looks really interesting but there is
one thing I don't quite understand. What makes access to fields of
Entry implementations thread-safe across producer and consumer
threads?

E.g. Entry.setSequence is called by a producer thread and
Entry.getSequence by a consumer thread. The AbstractEntry
implementation uses a non-volatile long field for the sequence. A
consumer thread would not be guaranteed to ever see the sequence value
written by a producer thread? The same would go for access to the
'value' field in ValueEntry in the performance test suite.

What's ensuring a happens-before relationship between reads and writes
here?

[Michael Barker]

The volatile cursor value in the ring buffer provides the necessary
memory fence. After the producer fills the entry it must call
ProducerBarrier.commit. The commit method will set the cursor value
to the same value as the sequence on the entry. Thereby making any
modifications to the entry visible to any thread that subsequently
reads the ring buffer's cursor value, which the
ConsumerBarrier.waitFor method does. So conceptually the commit
method is the write barrier and the waitFor method is the read
barrier.

Mike.

[wickedrob]

Thanks for the quick reply. As I had suspected, the problem was my
incorrect understanding of what volatile reads/writes mean. Your
answer and the section on volatiles on the JSR-133 FAQ page has
clarified things for me.

-- Rob