Re: [Caml-list] Thread behaviour

[Chet Murthy <murthy.chet@gmail.com>]

> OK, but this means that I can't think of OCaml code running in
> different threads in a simple way - I have to consider the single
> runtime lock at least (if I care about performance). So maybe the
> question is: how should I understand the functioning of the single
> runtime lock? For example, is starvation the only thing I need to
> think about?

Tom,

Yaron's note made a careful distinction between two things:
"concurrency" and "performance".  Let me explain a little more what
he's getting at.

"concurrency" means writing programs using constructs that look like
concurrent execution, for the purpose of .... well, for whatever
purpose you'd like, but usually modularity.

  --> in short, you don't care if your code's running on a single
      processor -- you just want to -write- it with multiple threads

  [of course, here you care about -starvation-, hence the worry about
  a tight loop with no possibility of suspension/"releasing the global
  lock"; but let's set that aside, since it's a different concern
  (even the LISPm, from what I remember, had issues here -- heck, so
  do some JVMs, for GC)]

"parallelism" means exploiting hardware facilities to -run- code in
parallel, usually for purposes of performance.

  --> you care very much if your code "properly" exploits
      SMP/multicore parallelism

When you speak of "performance", I'm going to guess that you're really
speaking of "parallelism" and not "concurrency".  If so, Ocaml's
threads are not for you, nor are monadic programming constructs.  Not
merely effectively, but -by- -construction- any threading system with
a global lock can only use a single CPU.  You can get more than that
from Ocaml, if Ocaml threads, spend a lot of time in C/C++ code that's
CPU-intensive.  But I'm assuming that that's not what you're looking
to do.

Does this help?
--chet--