[concurrency-interest] Immutable object conundrums
ashpublic at mac.com
Wed Jul 8 06:14:02 EDT 2009
So I think you are saying that from your knowledge of vm architectures
on various platforms it may not be possible to eliminate redundancy
the covers if you use an explicit fence through the Fences API and an
implicit fence through the final field modifier.
Lets assume then that an explicit fence is used instead of final fields.
I previously understood that the Fences API is supposed to
be platform independent at least w.r.t happens before behavior so that
future re-ordering compiler optimizations would have no adverse effect.
Are you saying that's not true and that there are current and possible
future platforms where the Fences API won't work?
As a final thought, I've been developing for many years and whilst I've
always had a fairly sound knowledge of thread fundamentals, I only
came to realize that most of my thread-safe code has only worked through
semi-luck after reading JCiP. In fact I've pinned it down to the
that I was inadvertently relying on: "in the same thread",
and "transitive". I would further extend this to the majority of
I have worked with. I dread to think of all the lazy instantiation
bugs that we must all have produced over the years.
So the reason I'm banging this drum is that I'm starting to think it's
a little dangerous to rely on implicit behavior to control the memory
model. Explicit API calls say "don't touch unless you know what you
are doing" a little louder. However if you say this isn't possible then
I'll add this to my ever growing list of things to think about.
On 8 Jul 2009, at 07:13, Jeremy Manson wrote:
> 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>
>> Just looked at the Fences API and this is exactly what I was trying
>> 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
>> final keyword without appearing to break the code.
>> Am I right in thinking most jvms would implement this by writing to
>> 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
>> 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