caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Hurt <bhurt@spnz.org>
To: John Goerzen <jgoerzen@complete.org>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Threading: Using and Building
Date: Mon, 12 Apr 2004 19:37:09 -0500 (CDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0404121928530.25700-100000@localhost.localdomain> (raw)
In-Reply-To: <20040412151948.GA11370@excelhustler.com>

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 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2004-04-12 23:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-12 15:19 John Goerzen
2004-04-12 17:12 ` Xavier Leroy
2004-04-13  0:37 ` Brian Hurt [this message]
2004-04-13  2:15   ` John Goerzen
2004-04-13  4:54     ` Brian Hurt
2004-04-13  7:44     ` Benjamin Geer
2004-04-13 19:47       ` David Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0404121928530.25700-100000@localhost.localdomain \
    --to=bhurt@spnz.org \
    --cc=caml-list@inria.fr \
    --cc=jgoerzen@complete.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).