[Caml-list] Threads question...

[Caml-list] Threads question...

[Corey O'Connor]

"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?
-- 
-Corey O'Connor

-------------------
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

Re: [Caml-list] Threads question...

[Jacques GARRIGUE]

From: "Corey O'Connor" <coreyoconnor@gmail.com>

> "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

-------------------
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

Threads question

[Raj Bandyopadhyay]

Hi all

I am using OCaml threads for an application that I am building.  
However, I don't require concurrency (which OCaml threads do not  
provide anyway). I'm using it only because it makes it far easier to  
express my algorithm.

I was wondering if there is a more lightweight thread library out  
there which works at the native code level and does not use system- 
level threads? I'd like to avoid the performance overhead of  
pthreads, if possible. The OCaml threads library does provide a vm- 
level thread, but it works only for bytecode :(

Thanks
Raj

Re: [Caml-list] Threads question

[Daniel Bünzli]

Le 10 oct. 07 à 16:43, Raj Bandyopadhyay a écrit :

> I was wondering if there is a more lightweight thread library out  
> there which works at the native code level and does not use system- 
> level threads?

I don't remember exactly how it is implemented but maybe Jérôme  
Vouillon's lwt [1] is what you are looking for. You can find it in  
the distribution of the Unison file synchronizer and in Ocsigen.

Best,

Daniel

[1] http://www.ocsigen.org/doc/lwt/Lwt.html