Although I am not sure about the accuracy of the information, this article claims that the only performance penalty of a volatile read on x86 is the loss of optimization possibilities: http://www.infoq.com/articles/memory_barriers_jvm_concurrency
With the Atomic* classes, the method lazySet (since 1.6) should be equal to setting a final field but without the only-once restriction. I interpret this to mean that writes in this thread that occur prior to the lazySet call, will happen-before other threads see the value from lazySet, whenever that is. I think the difference is that there is no happens-before relationship between the lazySet and subsequent reads in other threads. This isn't the volatile-write/non-volatile-read scenario, but to me the effect looks similar: the delayed visibility could just as well have been caused by an optimization of a non-volatile read. And although it seems consensus have yet to be reached, functionality for non-volatile appears to probably be coming to the Atomic*s in 1.7, in some form. But lazySet isn't terribly well documented and my understanding may be flawed, so I recommend getting a second opinion from the concurrency-interest list. On Wed, Apr 21, 2010 at 4:43 PM, Jochen Theodorou <[email protected]> wrote: > David Schlosnagle wrote: >> >> Rich and Jochen, >> >> Part of your needs might be met by Doug Lea's proposed Fences API [1] >> [2] for JDK7 by allowing an explicit volatile write (with the >> appropriate memory barriers), without incurring the overhead of a >> volatile read on each access. This fence could be used when a new >> method/function is registered, while all the lookups would be regular >> reference field accesses. The recent discussion of Fences and impacts >> to the Atomic* classes [3] might also be of interest as well since >> potential updates to the atomic field updaters could help build the >> functionality you desire. >> >> [1]: >> http://cs.oswego.edu/pipermail/concurrency-interest/2009-January/005743.html >> [2]: >> http://g.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html >> [3]: >> http://cs.oswego.edu/pipermail/concurrency-interest/2010-April/006990.html > > Those Fences sure look interesting to me. An explicit volatile write is what > I was looking for, so of course I am now excited to hear that something like > this is underway. > > bye Jochen > > -- > Jochen "blackdrag" Theodorou > The Groovy Project Tech Lead (http://groovy.codehaus.org) > http://blackdragsview.blogspot.com/ > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > -- Venlig hilsen / Kind regards, Christian Vest Hansen. -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
