Help me use my Dual Core CPU!

[Paul Rubin]

Michael <ms at cerenity.org> writes:
> > But ordinary programmers write real-world applications with shared data
> > all the time, namely database apps.  
> 
> I don't call that shared data because access to the shared data is
> arbitrated by a third party - namely the database. I mean where 2 or
> more people[*] hold a lock on an object and share it - specifically
> the kind of thing you reference above as turning into a mess.

Ehhh, I don't see a big difference between having the shared data
arbitrated by an external process with cumbersome message passing,
or having it arbitrated by an in-process subroutine or even by support
built into the language.  If you can go for that, I think we agree on
most other points.


> > This is just silly, and wasteful of the
> > efforts of the hardworking chip designers

> Aside from the fact it's enabled millions of programmers to deal with
> shared data by communicating with a database?

Well, sure, but like spreadsheets, its usefulness is that it lets
people get non-computationally-demanding tasks (of which there are a
lot) done with relatively little effort.  More demanding tasks aren't
so well served by spreadsheets, and lots of them are using databases
running on massively powerful and expensive computers when they could
get by with lighter weight communications mechanisms and thereby get
the needed performance from much cheaper hardware.  That in turn would
let normal folks run applications that are right now only feasible for
relatively complex businesses.  If you want, I can go into why this is
important far beyond the nerdy realm of software geekery.

> For generator based components we collapse inboxes into outboxes
> which means all that's happening when someone puts a piece of data
> into an outbox, they're simply saying "I'm no longer going to use
> this", and the recipient can use it straight away.

But either you're copying stuff between processes, or you're running
in-process without multiprocessor concurrency, right?

> This is traditional-lock free,

> > Lately I've been reading about "software transactional memory" (STM),

> I've been hearing about it as well, but not digged into it....
> If you do dig out those STM references, I'd be interested :-)

They're in the post you responded to:

  http://lambda-the-ultimate.org/node/463
  http://research.microsoft.com/users/simonpj/papers/stm/

In particular, the one about the GHCI implementation is here:

 http://research.microsoft.com/users/simonpj/papers/stm/lock-free-flops06.pdf

The Wikipedia article is also informative:

  http://en.wikipedia.org/wiki/Transactional_memory