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
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: -- (:)
From: Ted Kremenek <kremenek@c...>
Subject: Re: [Caml-list] Co-existing with non OCaml threads

Excellent.  I assumed that there was  second scheduler of some sort,  
but it wasn't clear how it was done.  Thank you very much for  
elucidating this.


On May 12, 2006, at 11:51 AM, Gerd Stolpmann wrote:

> Am Freitag, den 12.05.2006, 10:43 -0700 schrieb Ted Kremenek:
>> 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?
> Essentially they are pthreads, i.e. on Linux kernel threads. However,
> there is a level of cooperation on top of this.
>> 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.
> For all threads known to O'Caml we have:
> - Either the thread is running
> - Or it is waiting for the master lock (the kernel knows that,
>   and won't schedule this thread)
> - Or it is executing non-O'Caml code because it passed
>   enter_blocking_section.
> I hope it is now clear that getting the master lock is not the  
> problem.
> The trick is how a thread releases it.
> The running thread (that has the lock) is notified when it must  
> release
> the master lock. There is a special controller thread that  
> periodically
> checks whether the running thread ran too long. If so, a special
> notification mechanism will cause that this thread gives the master  
> lock
> up.
> Effectively, this is a second scheduler on top of the kernel  
> scheduler.
>>   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.
> No, this won't happen, because the kernel does not wake up threads
> waiting for a lock that is not free. These are kernel-level locks!
>> 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  ie..
>> 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?
> No this is not done.
>>   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.
> Performance is quite good, but you should keep in mind:
> - O'Caml code can never run on more than one CPU
> - Switches between O'Caml threads are less fine-grained than
>   between kernel threads. Imagine you stat a file, and it is
>   necessary to load some blocks from disk. This can take
>   0.01 s of time. During that time a switch is impossible.
>   (I.e. the problem is that there are system calls that are
>   non-blocking in general but that can nevertheless consume
>   lots of time in unlucky data cases.)
> Gerd
>> Just curious.  Thanks for the informative email.
>> Ted
>> 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()
> -- 
> ------------------------------------------------------------
> Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
> Phone: +49-6151-153855                  Fax: +49-6151-997714
> ------------------------------------------------------------