About Haskell Thread Model

[Yang, Qing]

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 at intel.com
86-10-85298800 Ext. 1955 (Office)
8751-1955 (iNet)

-----Original Message-----
From: Wolfgang Thaller [mailto:wolfgang.thaller at gmx.net] 
Sent: Sunday, October 12, 2003 4:58 AM
To: Yang, Qing
Cc: haskell at 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.