Christian Vest Hansen wrote:
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

does x86 include 64 bit systems? That is not fully clear in this article. It is quite common these days (even more in the future) to work on 64bit systems. and the loss of optimization possibilities can make Hotspot mostly useless.Not to forget bytecode instructed systems that realize systems on multiple machines.

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.

the basic question is if I can do safe publication with latySet or not.

bye blackdrag

--
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.

Reply via email to