[concurrency-interest] Immutable object conundrums
ashpublic at mac.com
Fri Jul 17 17:36:15 EDT 2009
Thanks to the many responses, just wanted to add a few more thoughts
thread to help any other concurrency newbies following behind me.
At first I found it difficult to see how to adapt my code to use
No matter how I baked it, I found myself removing problematic state
previously mutable classes, which rendered the code paths that could
be seen by
different threads as nothing more than functions.
Now in itself this isn't a problem but since I have long ago abandoned
and to some extent "is-a" style interfaces, then this additional
removal of state
means that the only OO feature I have left is encapsulation, i.e. the
like-minded methods in the same compilation unit. And even OO can't
Anyway to cut a long story short, if anybody else finds themselves
doubts about their long cherished OO practices, take a look at the
URLs, In particular the superbly eloquent clojure link was a real eye
opener to me:
It almost feels like I'm starting again from scratch.
On 1 Jul 2009, at 12:00, Ashley Williams 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 would
> be all too easy for a developer to come along and mistakenly remove
> the multi-purpose
> 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
>>> 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