[concurrency-interest] Nice video interview with TimHarrisandSimon Peyton-Jones

David Holmes dcholmes at optusnet.com.au
Thu Dec 28 05:59:55 EST 2006


Yes those guys are stalwarts :-) And Joe Seigh has a lot of experience in
this area too.

I've had some involvement with people working on STM over the past few years
and someone who recently wrote a thesis around it told me that they now
agreed with my position that there are too many non-transactional actions
involved in synchronization/coordination to make STM a general solution. But
I'm all for them trying.

Cheers,
David Holmes

Kimo Crossman wrote:
>
> The guys at comp.programming.threads pretty much hate the idea ...
>
> See lively attack of the video here:
> http://tinyurl.com/yj5u58
>
> including this later comment:
>
> "I'm not going to worry about STM.  The more I look at it the
> more it looks like locks without deadlocking.  They're not really
> going after scalability at all just as long as it doesn't suck
> too much.  Nothing to see here.  Move along."
> --
> Joe Seigh
>
> And more here about TM:
> http://tinyurl.com/y7fax3
>
> Hard issues:
> Large transations
> System and I/O calls
> Objects shared between two processes.
>
>
> ________________________________
>
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of
> Joshua Bloch
> Sent: 2006 December 27 23:18
> To: Philippe Monnaie
> Cc: Concurrency-interest at cs.oswego.edu; dholmes at ieee.org
> Subject: Re: [concurrency-interest] Nice video interview with Tim
> HarrisandSimon Peyton-Jones
>
>
> 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>
	> > [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
<mailto: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





_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list