caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ted Kremenek <kremenek@cs.stanford.edu>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: francois@rouaix.org, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Co-existing with non OCaml threads
Date: Fri, 12 May 2006 10:43:02 -0700	[thread overview]
Message-ID: <25A4782F-1F23-4B18-8FB2-1627C3BF1C3D@cs.stanford.edu> (raw)
In-Reply-To: <1147432929.19900.18.camel@localhost.localdomain>

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.

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


  parent reply	other threads:[~2006-05-12 17:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-12  0:29 Francois Rouaix
2006-05-12  3:27 ` [Caml-list] " Ted Kremenek
2006-05-12 11:22 ` Gerd Stolpmann
2006-05-12 16:10   ` Vincenzo Ciancia
2006-05-12 16:30     ` [Caml-list] " Markus Mottl
2006-05-12 17:43   ` Ted Kremenek [this message]
2006-05-12 18:51     ` [Caml-list] " Gerd Stolpmann
2006-05-12 19:24       ` Ted Kremenek
2006-05-12 20:44     ` Markus Mottl
2006-05-12 21:00       ` Ted Kremenek
2006-05-13  9:30 ` Xavier Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25A4782F-1F23-4B18-8FB2-1627C3BF1C3D@cs.stanford.edu \
    --to=kremenek@cs.stanford.edu \
    --cc=caml-list@yquem.inria.fr \
    --cc=francois@rouaix.org \
    --cc=info@gerd-stolpmann.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).