[concurrency-interest] Immutable object conundrums
ashpublic at mac.com
Mon Jul 20 08:33:44 EDT 2009
Thanks Ben for the quote, I'll add it to my collection. Or should I
say create a new
collection based on the old one with one extra element - sorry bad joke!
I also came across a talk by Rich Hickey that I found very instructive
if like me,
anyone is in the process of picking apart their programming style.
Although he talks about Clojure, the lessons translate very well into
It's quite long but you can probably skip the first 21 minutes and
also stop halfway when he delves
into the Closure code. Oh but pick it up again for the last 15
minutes. Here are some of the highlights:
* multimethods - like polymophism, but not just based on types, can be
based on other conditions
* quote: "immutable objects are the new spaghetti code"
* at one point he recommends reading concurrency in practice and that
it will scare you to death!
* he wrote java classes with static methods and no data, attracting
looks of horror from colleagues
* whether we like it or not we're all concurrent programmers now since
clock speeds have leveled off
and cpu architecture has spread into multiple cores
* CopyOnWrite collections have weakness, still requires locks for
compound actions and also mutator
methods take a long time. I don't wish to misrepresent him, he
admires the collection classes for
their domain of application.
* Clojure uses immutable persistent data structures that retain read/
write access times (Big O) and is
achieved by structural sharing techniques - nothing like this in
the java libraries.
* "Secret-sauce" of Clojure is the persistent hashmap and vector
structures - can never be any concurrent
modification exceptions thrown from these immutable objects.
* Adding multithreaded behavior to single threaded logic (changing
requirements) is close to impossible
* Closure has references to immutable targets but those references can
change in a coordinated fashion
* quote: "Fake in-system threads are over", we now have real threads
on real cpu cores.
* Refs are STM idiom, can only be reassigned inside a transaction.
Under the hood is a complex
implementation that uses multiversion concurrency control. This
keeps readers from blocking other
readers/writers and also writers never block readers.
* Hopes that java language won't change any more, makes maintenance of
Clojure more difficult
* Can use Clojure libraries from Java, Garbage collector loves Clojure.
This has answered at least one of my questions that immutable objects
aren't a silver bullet - although
perhaps an alloy of 90% silver. You still have to worry about the
parent (mutable) references, which in
Clojure is handled by an STM system. This is because with immutable
objects, the world is a series
of snapshots that eventually have to be reconciled.
In Java it looks like I will have to roll my own reference strategy
with locks and CAS techniques on top
level aggregate and it's not clear to me how this will work out. This
task is where I feel there is a
scarcity of examples to follow.
Just one more comment: I also found this paper that's worth a skim:
There is an excellent passage that I've pasted below, the tldr version
is essentially that todays
multi-threaded programs are broken and we will begin to see this with
increasing cpu cores:
"I speculate that most multithreaded programs
have such bugs. I speculate further that the bugs have not proved to
be major handicaps only
because today’s architectures and operating systems deliver modest
parallelism. The cost of context
switching is high, so only a tiny percentage of the possible
interleavings of thread instructions
ever occur in practice. I conjecture that most multi-threaded general-
purpose applications are, in
fact, so full of concurrency bugs that as multi-core architectures
become commonplace, these bugs
will begin to show up as system failures. This scenario is bleak for
computer vendors: their next
generation of machines will become widely known as the ones on which
many programs crash.
These same computer vendors are advocating more multi-threaded
programming, so that there
is concurrency that can exploit the parallelism they would like to
sell us. Intel, for example, has
embarked on an active campaign to get leading computer science
academic programs to put more
emphasis on multi-threaded programming. If they are successful, and
the next generation of pro-
grammers makes more intensive use of multithreading, then the next
generation of computers will
become nearly unusable."
On 20 Jul 2009, at 07:12, Ben Manes wrote:
> If you design OO based on Alan Kay's definition then there usually
> isn't an impedance issue:
> "I decided to leave out inheritance as a built-in feature until I
> understood it better... OOP to me means only messaging, local
> and protection and hiding of state-process, and extreme late-binding
> of all things. It can be done in Smalltalk and in LISP. There are
> possibly other systems in which this is possible, but I'm not aware
> of them." -- Alan Kay
> You can often mix functional programming ideas with object-oriented
> ideas and leverage a bottom-up, responsibility-driven approach. It
> may only seem incompatible because Java is usually written in a top-
> down OO model.
> From: Ashley Williams <ashpublic at mac.com>
> To: concurrency-interest at cs.oswego.edu
> Sent: Friday, July 17, 2009 2:36:15 PM
> Subject: Re: [concurrency-interest] Immutable object conundrums
> 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
> 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.
> - 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
> > 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
> > 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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest