Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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 Archives:
Bug reports: FAQ:
Beginner's list: