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