[concurrency-interest] Immutable object conundrums

Ashley Williams 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  
to this
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  
immutable objects.
No matter how I baked it, I found myself removing problematic state  
from my
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  
inheritance
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  
grouping of
like-minded methods in the same compilation unit. And even OO can't  
claim this
for itself.

Anyway to cut a long story short, if anybody else finds themselves  
with nagging
doubts about their long cherished OO practices, take a look at the  
following
URLs, In particular the superbly eloquent clojure link was a real eye  
opener to me:

http://clojure.org/state
http://www.scala-lang.org/

It almost feels like I'm starting again from scratch.

Cheers
- Ashley

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  
> Fences.preStoreFence()
> 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  
>>> 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
>> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/
>>
>> Plus Fences, which can't be previewed in jsr166y since
>> it relies on JVM support. See
>> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html
>>
>> 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.
>>
>> -Doug
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list