[Haskell-cafe] Dynamic thread management?

[Sebastian Sylvan]

On 11/08/07, Brian Hurt <bhurt at spnz.org> wrote:
>
> You guys might also want to take a look at the Cilk programming language,
> and how it managed threads.  If you know C, learning Cilk is about 2 hours
> of work, as it's C with half a dozen extra keywords and a few new
> concepts.  I'd love to see Cilk - C + Haskell as a programming language.
>
> The key idea of Cilk is that it's easier to deparallelize than it is to
> parallelize, especially automatically.  So the idea is that the program is
> written incredibly parallel, with huge numbers of microthreads, which are
> (on average) very cheap to spawn.  The runtime then deparallelizes the
> microthreads, running multiple microthreads sequentially within a single
> real thread (a worker thread).  Microthreads that live their entire life
> within a single real thread are cheap to spawn (as in "not much more
> expensive than a normal function call" cheap).
>
> The problem that Cilk runs into is that it's, well, C.  It doesn't deal
> with contention at well at all- a single microthread blocking blocks the
> whole worker thread- meaning, among other things, that you can have "false
> deadlocks", where one microthread blocks on another microthread in the
> same real thread, and thus acts like it's deadlocked even though it really
> isn't.  You have greatly increased the likelyhood of raceconditions as
> well (mutable data and multithreading just don't mix).  Plus you have all
> the normal fun you have with C bugs- wild pointers, buffer over runs, etc.
>
> All of which you avoid if you replace the C aspects of Cilk with Haskell.
> With STM you avoid the deadlock problem entirely, and with immutable data
> (except for carefully coded monads) you avoid the whole race condition
> problem.  Plus all the normal advantages Haskell has over C.
>

How is this any better than using "par" in Haskell?

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862