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

Kimo Crossman kimo at webnetic.net
Thu Dec 28 03:14:57 EST 2006


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
	






More information about the Concurrency-interest mailing list