Re: JavaMemoryModel: Programmer Oriented FAQ

From: Hans Boehm (
Date: Wed Feb 11 2004 - 23:59:09 EST

The advice in the FAQ seems reasonable to me, but I think the argument
behind it is not really correct. With the de-facto X86 memory model,
most implementations are likely to impose no overhead (other than
compiler reordering constraints) on volatile reads. For IA64, you need
an ld.acq instead of an ld; the cost of that generally seems to be
in the 0 to 10 cycle range depending on context. Volatile reads also
encounter no hardware overhead on PA-RISC. And I believe the same
applies to SPARC. In all of these cases, the cost is far less than
synchronization. And synchronization can force repeated transfers
of a cache line between processors, which volatile reads never will,
at least assuming a reasonable cache coherence protocol.

Volatiles will typically be appreciably cheaper than synchronization,
especially if the volatile variable is rarely written.


On Thu, 12 Feb 2004, Sylvia Else wrote:

> Hi,
> In the FAQ you appear to be suggesting that there is no longer any point in
> trying to implement the double checked lock parradigm, because the cost of
> using a volatile approaches that of locking under JSR133.
> On the 30th of October, on this list, Hans Boehm replied to a question of
> mine on this subject, under the topic "Re: JavaMemoryModel: JMM and caches."
> The answer I got there seemed to indicate that, at least on some
> architectures, we can still expect locking to have a significant cost
> compared with the use of volatile. This shouldn't be surprising, because
> locking provides an additional guarantee of atomicity w.r.t to other
> accesses of the same memory location that a simple volatile read or write
> does not.
> Sylvia.
> At 04:58 PM 11/02/2004 -0500, you wrote:
> >Hi folks,
> >
> >Brian Goetz and I have put together an introduction to memory model issues
> >which may be more accessible to the average multithreaded programmer. It
> >is probably a useful document to publicize to those who may ask you about
> >these issues.
> >
> >Also, we'd like to hear your feedback, if you have any.
> >
> >It's available at:
> >
> >
> >
> > Jeremy
> >-------------------------------
> >JavaMemoryModel mailing list -
> -------------------------------
> JavaMemoryModel mailing list -

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:57 EDT