Wolfgang, According to the User Guide of GHC 6.1 that GHC supports both Concurrent Haskell and Parallel Haskell. And Concurrent Haskell and Parallel Haskell have very different purpose. To my understanding about the document and your reply, it's Concurrent Haskell who uses Threads to process tasks concurrently and the threads are actually user-level thread. And no SMP is supported now in Concurrent Haskell. Is this right? For Parallel Haskell, it is said in the User Guide document as follows: ----------------------- Parallel Haskell is about speed - spawning threads onto multiple processors so that your program will run faster. ...... A Parallel Haskell program implies multiple processes running on multiple processors, under a PVM (Parallel Virtual Machine) framework. ...... ------------------------ Do you have some experience or knowledge about Parallel Haskell? And what you mentioned in you previous email is all about Concurrent Haskell or about the both? Thanks, Qing Yang System Software Lab Intel Corporation qing.yang@intel.com 86-10-85298800 Ext. 1955 (Office) 8751-1955 (iNet) -----Original Message----- From: Wolfgang Thaller [mailto:wolfgang.thaller@gmx.net] Sent: Sunday, October 12, 2003 4:58 AM To: Yang, Qing Cc: haskell@haskell.org Subject: Re: About Haskell Thread Model
I am a new learner of Haskell and I am interested in Haskell's concurrent model. Can somebody give me a brief intro about Haskell's thread model, like how the use-level threads are mapped to kernel thread and what scheduling mechanism that Haskell uses, or point me to some links or documents that I can learn from.
In the interpreter Hugs, all Haskell threads are run in one kernel thread. They are scheduled cooperatively; thread switches only take place when a function from the "Concurrent" module is called. In the currently released version of GHC, all Haskell threads are run in one kernel thread, too; however, thread switches can take place whenever memory is allocated --- and in Haskell, that means "almost always". The optimizer manages to compile a fibonacci function that doesn't allocate any memory, but in the real world, it's as good as real preemption. If you compile the bleeding-edge GHC from the CVS HEAD, you'll get something else; while "most" threads (those created using "forkIO") are still light-weight threads that are scheduled in just one kernel thread, you can also create threads that get their own operating system thread. This is solves all the problems that lightweight threads can have with foreign (i.e. non-Haskell) libraries. You should also note that no Haskell implementation currently supports SMP; even when multiple kernel threads are used, there is a mutual exclusion lock on the Haskell heap, so a multithreaded Haskell program will use only one CPU on an SMP system. I hope my answer was useful... Cheers, Wolfgang P.S.: If you want to do me a favour, you could tell your mail program not to send multipart or HTML messages to the list; they look terrible to people like me who get a daily digest from the mailing list.
Do you have some experience or knowledge about Parallel Haskell? And what you mentioned in you previous email is all about Concurrent Haskell or about the both?
Everything I said was about Concurrent Haskell. I have no experience with Parallel Haskell. All the binaries available on the GHC web page are built for Concurrent Haskell. Cheers, Wolfgang
On Mon, 13 Oct 2003, Wolfgang Thaller wrote:
Do you have some experience or knowledge about Parallel Haskell? And
Parallel Haskell runs, but there are problems. Unless someone has slipped something past me, there is no parallel implementation for Release 6 yet, so if you want to tinker with it, you'll need to go to the CVS repository for Release 5 of Haskell and the parallel run-time system (look for the GUM branch). Please note, the Release 5 version of parallel Haskell should be considered experimental and best left aside if you are unwilling to fix code. Murray Gross Metis Project, Brooklyn College
participants (3)
-
mgross@dorsai.org -
Wolfgang Thaller -
Yang, Qing