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

Joshua Bloch josh at bloch.us
Thu Dec 28 14:56:35 EST 2006


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?

           Josh


On 12/28/06, Khilan Gudka <kgudka at gmail.com> wrote:
>
> Hi,
> 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.
>
> Khilan
>
> On 12/28/06, Joshua Bloch <josh at bloch.us> wrote:
> >
> >  Brian,
> >
> > 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.
> >
> >            Josh
> >
> >
> > On 12/28/06, Brian Goetz <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
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061228/b66642e7/attachment-0001.html 


More information about the Concurrency-interest mailing list