[Caml-list] Threads question...
Corey O'Connor
processor. It will not take advantage of multi-processor machines.
Using this library will therefore never make programs run faster.
However, many programs are easier to write when structured as several
communicating processes."
However, the documentation states that the native threads library is
implemented using the system's native threading. (POSIX threads, in my
case)
Is the quote above still consistent with the native threads implementation?
--
-Corey O'Connor
-------------------
To unsubscribe, mail caml-lis...@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
Jacques GARRIGUE
> "The threads library is implemented by time-sharing on a single
> processor. It will not take advantage of multi-processor machines.
> Using this library will therefore never make programs run faster.
> However, many programs are easier to write when structured as several
> communicating processes."
>
> However, the documentation states that the native threads library is
> implemented using the system's native threading. (POSIX threads, in my
> case)
>
> Is the quote above still consistent with the native threads implementation?
Basically, yes.
With posix threads (or windows threads), every caml thread is mapped
to a posix thread, but there is a global mutex which any caml thread
must obtain before running. This makes sure for instance that memory
allocation and GC work properly.
So no more than one caml thread may run simultaneously, and you don't
gain from multiple CPUs.
However, contrary to vmthreads, this restriction only applies while
executing caml code. If you call some C function, you may choose to
first release the global lock (caml_enter_blocking_section), letting
other caml threads work while you are on the C side. Don't forget to
call lock again (caml_leave_blocking_section) when returning, or you
will crash very soon.
Jacques Garrigue