[Caml-list] Thread in OCaml

[Caml-list] Thread in OCaml

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]


My recent problems with threads suggest the following questions

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.

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

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 ?

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

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


-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] Thread in OCaml

[Daniel Bünzli]

Le 16 avr. 04, à 12:30, Christophe Raffalli a écrit :

> 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.
I guess it is to suggest that you are going to enter a section where C 
calls may block. The names were given from the perpsective of what 
happens between enter/leave.

In my opinion, what really doesn't help is that it is not documented 
_at all_ in the the manual...

> 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
Using a library should not interfere with other part of the ocaml 
system. Since glut has this (bad) idea of a loop that never returns 
enter/leave_blocking_section should _always_ be used in the stubs so 
that signal handlers (see Sys.signal) can be executed. Note that in 
that case it is important that the callbacks from C into caml 
reacquires the lock via leave_blocking_section and releases it after 
(or a signal handler could be executing caml code concurrently with a 
callback).

Daniel

P.S. In your previous post is not clear to me what you are actually 
measuring.
-------------------
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] Thread in OCaml

[Damien Doligez]

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

Re: [Caml-list] Thread in OCaml

[Christophe Raffalli]

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

I beleived that only the compaction Gc moved value.
But I guess that value are mover from the minor heap to the major heap ...

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

Will there be one for OCaml
-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

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