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

Kimo Crossman kimo at webnetic.net
Thu Dec 28 20:51:12 EST 2006

Here is by the way a current bibliography of Software and Hardware Transactional Memory


From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Joshua Bloch
Sent: 2006 December 28 11:57
To: Khilan Gudka
Cc: Brian Goetz; Concurrency-interest at cs.oswego.edu; dholmes at ieee.org
Subject: Re: [concurrency-interest] Nice video interview with Tim HarrisandSimon Peyton-Jones

It's funny; Al Spector (my thesis advisor) and I discussed hardware support for transactional memory when I was at CMU (~1988).  We decided it was way premature.  These days, I would say "a bit premature."  The thing about hardware is that the startup costs are very high, and you have to plan to get one (or two) generations wrong.  So once again, I see it as a promising research area, rather than a market imperative.  That said, I really haven't kept up with the area, so what do I know? 

On 12/28/06, Khilan Gudka <kgudka at gmail.com> wrote: 

I agree. STMs also have a number of other subtle problems like not being able to support strong atomicity due to the ABA problem with CAS instructions. Plus current solutions for IO are not general enough. Do you think hardware support is a possible reality or just a dream? the Hybrid Transactional Memory proposal seems to be a lot more realistic than previous hardware-only suggestions, although I guess this is up to chip manufacturers. 


On 12/28/06, Joshua Bloch <josh at bloch.us  <mailto:josh at bloch.us> > wrote: 

Yes, I think we're in agreement.  I a big fan of STM as a research topic.  I just don't think it's ready for prime time yet.  In particular, I don't think we really have a handle on how it will feel to programmers. 

On 12/28/06, Brian Goetz <brian at quiotix.com  <mailto:brian at quiotix.com> > wrote: 

> Hmmm.  I remember people bitching about GC performance, but not 
> usability.

I remember people bitching about unreliability, too, though those were 
mostly out of ignorance.  FUD items like pointers hidden from the
collector (newP = p XOR 0xCAFEBABE; p=0) and cyclical data structures
that can't be reclaimed by reference counting. 

> I'm saying that the transaction model is not as easy to 
> program to as it appears, and it does not free you from thinking about
> locks (in my experience with Encina and Camelot).  Did people bitch 
> about the usability of GC?

A sufficiently large quantitative difference becomes a qualitative 
difference.  If the performance is so poor, you'll do all sorts of
things to avoid using it, and then its as if you don't have it, and you 
bitch about that.

People understand "one big fat lock".  People don't use OBFL because 
they are convinced the performance would suck.  If we could make the
performance of OBFL better, I think many of the usability issues go away 
_relative to the current audience_.

But, of course, once you make things easier, the audience grows, and the 
new expanded audience might not see the subtleties of "don't do I/O in
atomic blocks" and things like that. 

I don't want to come off as having drank the kool-aid -- I think there's
a long way to go before STM is real (though the Azul implementation is a 
nice proof for the concept) -- I just think that many of the arguments 
raised against it are the same as those that have been raised against
many other fledgling technologies that we've since come to love.  I am 
anxiously hoping the research boys come up with something good here, 
because what we've got now is a bunch of bananas.

Concurrency-interest mailing list 
Concurrency-interest at altair.cs.oswego.edu  <mailto:Concurrency-interest at altair.cs.oswego.edu> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061228/76312ee2/attachment.html 

More information about the Concurrency-interest mailing list