Re: [Caml-list] Co-existing with non OCaml threads

[Ted Kremenek <kremenek@cs.stanford.edu>]

Gerd,

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.

Ted

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
> gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
> Phone: +49-6151-153855                  Fax: +49-6151-997714
> ------------------------------------------------------------
>