Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 2008-07-28 03:09 -0700 (Mon), Josh Glover wrote:

> 2008/7/28 Curt Sampson <cjs@example.com>:
> 
> > But let's try this on for size: what is it about Haskell's STM interface
> > definition that might make it not work where "traditional" composition
> > of locks, as in most threaded Java applications I've seen, would work?
> 
> The point is this: I read Attila's question as, "Has anyone on the
> list direct experience with using STM? Does it work as advertised?"
> Your answer sounds like, "No, but it should work."

Well, I was thinking of the original question, which was, "how does it
scale?"

I've played with STM a bit, and it does work as advertised in stuff the
size of the example in the paper. 

Are the locking primitives that STM relies on likely to fail? No more so
than Java; this stuff is heavily used. I rely on it for mission-critical
stuff.

Is what STM adds to the locking primitives likely to fail? I don't see
how; this is type system stuff. A TVar is basically just an MVar, as far
as I can tell.

As to how it scales, I fail to see how it couldn't scale far, far better
than the alternative of working out all of the locking manually for
every different composition of transactions.

I did plenty of thread programming in Java way back when, and it's truly
nasty stuff. I'm using threads regularly in Haskell right now, though
my stuff is simple enough at the moment that MVars and Channels do
everything I need.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links