[concurrency-interest] Nice video interview with Tim Harris andSimon Peyton-Jones

Joshua Bloch josh at bloch.us
Thu Dec 28 02:18:14 EST 2006


I too have my doubts.  I programmed general purpose transaction systems of
an earlier era (Camelot and Encina, for the terminally curious), and they're
harder to program in practice than they appear in theory.  Of course the
analogy between these systems and STMs is imperfect, but not entirely bogus,
I think.

     Josh

On 12/27/06, Philippe Monnaie <Philippe.Monnaie at gmail.com> wrote:
>
> I indeed have my doubts as well on STM making concurrency that much
> easier. But I have to say it does offer some advantages on the side.
> The abort/retry semantics make your program immune to deadlock, and
> STM should make abstraction easier by making synchronization
> structures composable.
>
> On the other hand, a program with heavy data sharing, would produce
> lots of collisions, leading to starvation and performance slowing down
> to a crawl. So I have to agree that it won't work in every case.
>
> Concerning the latter part of your comment, would it be possible to
> solve this with design techniques, much like object oriented
> programming simplified writing larger programs?
>
>
> - Philippe
>
> On 12/27/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> > STM is just the latest (incomplete!) attempt at providing a system that
> > takes care of concurrency for you. I am not a believer. There are too
> many
> > different kinds of interactions that undermine a "one size fits all"
> > approach. Time will tell ...
> >
> >
> > The problem with concurrency is not the "materials" but the general
> > architecture. First you need to understand your sharing and atomicity
> > requirements and then you have to enforce them. Where people fail is in
> the
> > first step - understanding the problem - but it manifests in the second
> and
> > so we blame the mechanism as being too hard to use.
> >
> > The issue isn't "bananas" for building skyscrapers, it's thinking you
> can
> > build a skyscraper just because you built a tree-house (or in some cases
> > because you read the plans for a tree-house!).
> >
> > Of course the counter-argument is that perhaps locks and threads are
> only
> > good for building "tree houses", even if you do know how to build a
> > "skyscraper".
> >
> > Cheers,
> > David
> >
> > > -----Original Message-----
> > > From: concurrency-interest-bounces at cs.oswego.edu
> > > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Brian
> > > Goetz
> > > Sent: Thursday, 28 December 2006 5:44 AM
> > > To: Concurrency-interest at cs.oswego.edu
> > > Subject: [concurrency-interest] Nice video interview with Tim Harris
> > > andSimon Peyton-Jones
> > >
> > >
> > > http://channel9.msdn.com/Showpost.aspx?postid=231495
> > >
> > > Lousy interviewer, but good interviewees, talking about transactional
> > > memory and the future of concurrency.
> > >
> > > My favorite quote (paraphrased): "Building concurrent programs with
> > > locks is kind of like building a skyscraper out of bananas.  Smart
> > > people can come up with clever techniques for hooking bananas
> together,
> > > but the result is still fragile.  Rather than investing energy in
> > > mastering banana-coupling techniques, it would be better to invest it
> in
> > > better materials."
> > > _______________________________________________
> > > Concurrency-interest mailing list
> > > Concurrency-interest at altair.cs.oswego.edu
> > > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061227/4af64078/attachment.html 


More information about the Concurrency-interest mailing list