[Haskell-cafe] Dynamic thread management?
sebastian.sylvan at gmail.com
Sat Aug 11 12:48:46 EDT 2007
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?
More information about the Haskell-Cafe