Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Thread in OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Damien Doligez <damien.doligez@i...>
Subject: Re: [Caml-list] Thread in OCaml
On Apr 16, 2004, at 12:30, Christophe Raffalli wrote:

> 1) why the name enter(resp leaving)_blocking_section to release(resp 
> aquire) a mutex ? you aquire a mutex when you want to block other 
> threads. The name seems inversed to me and this did not help.

As Daniel said, they are supposed to be placed before and after a piece
of code that may call blocking system calls (like read, for example).

> 2) is there a way to have two files wrap_glut.c one with 
> enter/leaing_blocking_section the other without (or MACROS), the right 
> file being used depending if the -thread or -vmthread option is given

I think you're supposed to use them in all cases.  If it doesn't
work, I want to know about it.

> 3) I know a little (not much) about the runtime system of OCaml and I 
> think (probably wrongly), that it would be enough to aquire a mutex 
> when allocating heap object (for this you need a list of grey-val for 
> each thread but it should not be difficult). What am I missing about 
> the runtime ?

Allocating can call the GC, and the GC can move values around, which
invalidates pointers.  Even read-only access to the heap is impossible
during the GC.

> If you think a typical Caml program spend 20% of time during 
> allocation(which include GC) then 5 threads could run concurrently on 
> 5 CPUs with some speedup (up to 5 times in the best case).

If only it was so easy to make a good concurrent GC...

> Remark: for me it is to the programmer to add mutex if a mutable is 
> being written/read by more that one thread.

Of course.  The current Caml threads already make this assumption,
since they are preemptive.

-- Damien

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