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