[concurrency-interest] Immutable object conundrums
ashpublic at mac.com
Wed Jul 1 07:00:59 EDT 2009
Just looked at the Fences API and this is exactly what I was trying 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 would
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
main memory (writes) and
evicting entries from local memory (reads)? Just wondering about any
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
>> 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
More information about the Concurrency-interest