[concurrency-interest] Immutable object conundrums
jeremy.manson at gmail.com
Wed Jul 8 02:13:58 EDT 2009
Most VMs would implement this by executing the appropriate fence
instruction (as you describe) and preventing compiler optimizations
that moved accesses around the Fence. A VM might be clever enough to
combine the fences for this and final fields, but it might not. I
doubt such an optimization would happen in any timely manner, but who
I would argue that this method is definitely *not* preferable to use
of the final keyword. "final" implies something about the semantics
of field access on both the reader and writer side, and the fence
implies something platform-dependent about the store you are putting
it before. On the off chance that there is ever a platform that
requires the reader to do something to guarantee coherence, all of the
code written using this Fences API will break.
(None of the hardware platforms that Java currently really supports
(i.e., SPARC and x86, plus, to a lesser extent, PPC and ia64) require
reader-side coherence guarantees. There is always the possibility
that someone will come up with a compiler optimization that breaks
reader-side dependencies in a way that would require additional
guarantees for reading final fields, although such optimizations would
probably be highly suspect. Anything that used a distributed shared
memory style of programming (or whatever they are calling it these
days) would also possibly break.)
In my opinion, such as it is, replacing something with well-defined
semantics with something that happens to work on the platforms you
know about is something that is highly suspect as a general principle,
and should only be used for very, very particular use cases.
On Wed, Jul 1, 2009 at 4:00 AM, Ashley Williams<ashpublic at mac.com> wrote:
> Just looked at the Fences API and this is exactly what I was trying to
> allude to.
> In fact I would personally prefer to see the explicit use of
> instead of relying on memory model guarantees through the use of final. It
> be all too easy for a developer to come along and mistakenly remove the
> final keyword without appearing to break the code.
> Am I right in thinking most jvms would implement this by writing to main
> memory (writes) and
> evicting entries from local memory (reads)? Just wondering about any
> performance costs.
> So if one were to use both a final field modifier as well as a fence, would
> the jvm be
> clever enough not pay the for the happens-before guarantee twice over?
> On 30 Jun 2009, at 21:46, Doug Lea wrote:
>> Peter Veentjer wrote:
>>> PS: Do you have a reference to the other concurrency features that are
>>> going to be added (apart from the fences and the fork/join
>>> functionality) to Java 7?
>> Definitely planned classes are in package jsr166y --
>> ForkJoin, Phasers, TransferQueue, ThreadLocalRandom. See
>> Plus Fences, which can't be previewed in jsr166y since
>> it relies on JVM support. See
>> Plus possibly some sort of customized hash map.
>> The main reason for delay on that is algorithmic:
>> Efficient support for features like eviction and
>> memoization across a large enough range of
>> policies to be worth supporting in concurrent maps is not a
>> fully solved problem. I want to make sure that
>> we offer only that range of them for which we are
>> very sure we can support well, but without closing
>> the door to future algorithmic overhauls.
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest