[tlug] STM (was: Re: work times & accommodation @tokyo)

[Attila Kinali <attila@example.com>]

On Fri, 25 Jul 2008 06:19:54 +0900
"Stephen J. Turnbull" <stephen@example.com> wrote:

> And what problem does use of Haskell solve for Google?  Google's big
> problem is concurrency.  So is STM a standard part of GHC 6.8?  How
> well-debugged is it?  Can you refer me to the HOWTOs on using it to
> solve google-sized problems?  How does this interface with modules
> written in other languages that don't have STM?  Is it as efficient as
> SP-J's chapter in "Beautiful Code" would suggest, or does it require
> problems that are as easy to factor in your head as the toy problem he
> presents there?

Does STM work in real world applications?
I'm more or less following the development of TM and
especially STM for a few year years now, out of personal interest.
But my judgment from when i first heard about it, that
the proponents of STM think, that it's not locking if it's
done in hardware, is simply wrong. Yes, locking in hardware
is so much faster, that a lot of the problems of locking in
software are magicaly "solved" (because they are depending on
the time the lock is held). But they will strike back when
the machines we work on become so much faster, that the locks
in hardware exhibit the same problems we have today in software.

What i think the problem is, that our programming languages
today have a very bad abstraction of concurency and that
the solution lies in the programming language rather then
in a new way of locking. Not to mention that TM comes with
a lot of problems of its own, a few of which (especialy
performance problems) are summerized in Jayaram Bobba's
paper "Performance Pathologies in Hardware Transactional
Memory"

				Attila Kinali

-- 
The true CS students do not need to know how to program.
They learn how to abstract the process of programming to
the point of making programmers obsolete.
		-- Jabber in #holo