[concurrency-interest] a question regarding SeqeuenceLock
hans.boehm at hp.com
Mon Aug 1 12:30:21 EDT 2011
The use of volatile should also remind you that these are potentially racing reads, and you get very few guarantees about the consistency of the values you see. You cannot call an arbitrary read-only method inside such a read-only critical, since it can see inconsistent state. You will eventually discover that there was a race, and you need to retry. But there are likely to be subtleties involved in guaranteeing that nothing crashes in the meantime. SequenceLocks are really very strange beasts. I view them as very much an experts-only facility, though potentially a useful one.
I also think that Doug is a bit optimistic about working around the volatile restriction in a way that is not dependent on the JVM implementation. We had a prior discussion of this, and it does appear to be mostly safe given current standard JVM implementations, but that's largely accidental. Fundamentally, the roach motel guarantees do not require that non-volatile reads in a read-only critical section become visible before the end of the critical section. Using non-volatile reads here means that your code has data races, implying that you need to reason about the full Java memory model (which we don't actually know how to do), and you are leaving the sequentially consistent subset. It also means that running a data race detector on your code will become more painful.
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-
> interest-bounces at cs.oswego.edu] On Behalf Of Doug Lea
> Sent: Monday, August 01, 2011 3:42 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] a question regarding SeqeuenceLock
> 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
> > (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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest