This seems to match the observed behavior on my machine. I could infer 
that the two threads were being executed in parallel; just not on 
different processors simultaneously. Thank you very much!!

On Friday, February 21, 2003, at 07:11 AM, Jacques Garrigue wrote:

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

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