Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] native threads not parallel?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] native threads not parallel?
From: shivkumar chandrasekaran <shiv@ece.ucsb.edu>
> Sorry, but let me ask again. I *know* that ocaml threads cannot use
> multiple processors. That was not the subject of the thread I cited. I
> should have been clearer.
>
> If I am recalling correctly, Xavier has mentioned before that in
> *native-code* (see subject) ocaml will allow C code to run in parallel.
> Markus' email was precisely on that point as was mine. I have C code
> that I would like to execute on a processor different from the ocaml
> thread one. Apparently, as I gather from the cited email of Markus
> Mottl, this did occur (at least on some dual processor Linux machines)
> when the corresponding C code was bracketed with "enter/leaving_blocking
> section ()" calls, and, *I assume*, calling the C-code from a separate
> ocaml thread using Thread.create.

I see, after rereading carefully the original mail, I could understand
what this is about.

IIRC, the distinction is not between native code and bytecode, but
between native threads and caml threads. You can use native threads in
bytecode, and it should work also (but I might be wrong).

About the problem Markus is describing, and if he is using
Thread.create as you suggest, I may see a cause.  Seeing that the code
for caml_thread_new in posix.c contains no enter_blocking_section, if
you create a thread with Thread.create, it will immediately block
trying to get the caml mutex. It will get it eventually from the main
caml thread through a yield, but a clever scheduler will schedule this
thread on the same processor (it starts just when the previous one
stops). As Markus says, after a long time the scheduler may realize
this choice was wrong and change the processor, but this is scheduler
dependent.

I may be utterly wrong in my inference, but if this is right, a better
solution would be to explicitely start the thread with pthread_start
from the C side.

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