English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Co-existing with non OCaml threads
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-05-12 (17:43)
From: Ted Kremenek <kremenek@c...>
Subject: Re: [Caml-list] Co-existing with non OCaml threads
This is very interesting.  Thank you for pointing this out.  I have  
some questions that would clarify a few things for me.

Because of the run-time lock, should I gather that the threads are  
still essentially cooperative threads?  For example, does it work  
this way: if a thread holding the master lock is switched out and the  
kernel schedules another thread, that other thread will start running  
and try and acquire the lock.  It won't be able to, so it goes back  
to sleep, and another thread will wake up, try and acquire the lock,  
goes back to sleep, and so on, until the original thread holding the  
lock is rescheduled.  Only when the thread releases the lock  
(yields?) will another thread be able to run.  Is this how it works?   
If so, this would lend itself to extremely poor performance: if I had  
100 threads, 99 of them may have to wake up and go to sleep before  
the original one is scheduled.  That is 99 useless context switches.   
Or rather is the lock acquired and released (within the generated  
native code for the OCaml part of a program, not C code) on calls to  
the memory management functions and other run-time code that are not  
thread-safe?  This is also seems slow, since the heap is actively  
manipulated all the time, so locks will constantly be acquired and  
released, and you will have the same wake-up, make little or no  
progress and go back to sleep problem I mentioned before.

Your last email said that only one thread is allowed to run OCaml  
code at any time, so it seems to me that this mutual exclusion must  
come from somewhere.  I'm very curious to know how this is  
implemented.  I gather that most people want to use threads in OCaml  
to have multiple threads running OCaml code, and not necessarily have  
a bunch of threads executing called C code (allowing the master lock  
to be released).  I'm just trying to understand how actual  
performance would ever resemble anything desirable.

Just curious.  Thanks for the informative email.


On May 12, 2006, at 4:22 AM, Gerd Stolpmann wrote:

> If you compile ocaml with pthread support, the O'Caml threads are real
> Linux threads. When using them, be aware of:
> - The memory management code is not thread-safe. That means
>   only one thread is allowed to run O'Caml code at any time.
>   To ensure this there is the so-called "master lock". You
>   can acquire the master lock by calling
>   leave_blocking_section()
>   and you can release it by
>   enter_blocking_section()