Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Threading: Using and Building
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] Threading: Using and Building
On Mon, 12 Apr 2004, John Goerzen wrote:

> Hello,
> I am looking at using multi-threaded programs in OCaml, but have some
> questions:
> *** Regarding the thread support itself
> Chapter 24 of the OCaml documentaion says that "The threads library is
> implemented by time-sharing on a single processor.  It will not take
> advantage of multi-processor machines."  That's bad.
> But then later on I notice that there are two threading options: system
> threads and VM-level threads.  The introductory paragraph does not seem
> to apply to system threads which, in other languages at least, do not
> behave that way.  So I am rather puzzled about the actual level of
> thread support is here.

The threading is all user-space threading.  It doesn't take advantage of 
multiple CPUs, doesn't use system threads, if one thread blocks they all 
block, etc.

There are two problems with multithreading.  First, it makes the GC more
difficult and more costly.  Currently, the GC runs in the same system
thread as everything else, and thus it doesn't have synchronization
issues.  In a multi-threaded environment, you have synchronization issues
which slows things down.  Second, most people don't know how to write
safe, correct, efficient multithreaded programs.  It's harder than it
looks.  I think something like MPI between seperate processes would be a 
better way to take advantage of multi-processors.

On Unix, you don't lose much doing multi-proccess (forks) instead of
threads.  Switching between processes in Unix isn't any slower than
switching between threads within a process.  But I've seen benchmarks
which show that task switching between seperate processes was
signifigantly slower than switching between threads within a process on
NT4 (and that switching between threads on NT4 was about as expensive as 
switching between processes on Unix).  They may have fixed this, or they 
may not have.

"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: