[concurrency-interest] a question regarding SeqeuenceLock

Doug Lea dl at cs.oswego.edu
Mon Aug 1 06:42:13 EDT 2011

On 08/01/11 05:00, Yechiel Feffer wrote:
> In the api doc it is mentioned that awaitAvailability api should be used (as
> demonstrated in the Point class) in conjunction with reading volatile variables
> (in the Point class it is the x and y vars)
> Why the need for volatile ? the sequence # is a volatile (barrier) tested by
> awaitAvailability and updated by unlock() , so x and y will be visible without
> being volatile

There are a few reasons for placing this advice in the javadocs.
One is that if the fields are long or double, they should be
volatile to ensure atomicity. Also, the "roach motel"
properties of the JMM/JLS specs allow non-volatile reads
to be reordered below volatile reads in some cases. If you
are an expert in the subtleties of the JMM, you may be able
to work around these issues without always only reading
volatiles or values dependent on those reads. But given that
SequenceLocks are mainly applicable when reads overwhelm writes,
and that volatile reads are normally much cheaper than volatile
writes, there's rarely any reason not to follow this advice.
For example, some tests of the sample jsr166e.extra ReadMostlyVector
class showed no consistent performance differences using volatile
vs non-volatile internal fields across Intel, AMD, and
Sparc multiprocessor test machines.


More information about the Concurrency-interest mailing list