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

[Curt Sampson <cjs@example.com>]

On 2008-07-28 08:05 -0700 (Mon), Josh Glover wrote:

> It does indirectly, unless I am misunderstanding you altogether (which
> is entirely possible). I would hazard that a lot of your locking
> problems originated from attempts to parallellise algorithms, right?

Nope. This was back in '99 and 2000: we were running everything except
our database servers on single-core, single-CPU systems at the time, so
no parallelism was available.

Our multi-threaded stuff was entirely due to blocking IO: we needed
different threads for each dynamic HTTP request, due to blocking on IO
to the web server, the DBMS, and a few other things, we had separate
threads for a control console built into each server that let us inspect
things and change configuration parameters on the fly, and so on. The
locking issues came in with shared data such as DBMS connections (that
one was a real ouchie), shared large data structures (or even smaller
ones such as sessions), and so on.

> There are certainly other uses for threads and the necessity of
> locking that they breed, but I guess that parallellisation is one of
> the major use cases.

Maybe if you do everything in an event-driven framework. :-) Java, early
on, was never very amenable to that.

> Fork/join gives you that for free, and handles the locking with no
> explicit code on your part.

Fork/join handles no locking at all. If two separate threads spawned by
that access the same data structure at the same time, and you haven't
taken care of all of the locking, you're in big trouble.

> I guess this is how GHC's "par" works, right?

Nope. `par` offers no locking; you need to use explicitly shared data
structures and locks. The reason par works so well in Haskell is the
style of the language: since you're writing mostly pure code ("pure",
by the way, is a term of art here) you don't modify existing data
structures, you copy what you need new versions of. Note that this does
not preclude data sharing, in fact it encourages it in that the new
versions will re-use existing data wherever they can.

> What other languages have something analogous to "par"?

In the sense of, "spark a separate thread for doing this," lots.
In the sense of threads being that lighweight, not all that many
implementations, I'd imagine. (A GHC thread uses only a few hundred
bytes of memory, and it's fine to spark several thousand of them.) In
the sense of making it that easy to use, i.e., changing

    fib n = fib (n-1) + fib (n-2)

to

    fib n = r `par` (l `pseq` l+r)
        where
            l = fib (n-1)
            r = fib (n-2)

I don't know of anything off-hand.

> For that matter, what languages are supported by GHC? Just Haskell, or
> other languages in that family?

Just Haskell. Though, come to think of it, you probably could tack
on a new front end that compiles something else to its "primitive"
Haskell-like code and then use the rest of GHC to compile that.

Oh, BTW, while we're talking about parallelism, I should mention
that GHC now has parallel GC implemented (as in, GC that still stops
everything else, but uses multiple cores to do the collection faster
than a single core could do it alone) and it will be released with GHC
6.10 this fall. It apparently gives GC about a 20% speedup on a two-core
machine, and 45% on a four-core.

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