Browse thread
Co-existing with non OCaml threads
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Gerd Stolpmann <info@g...> |
| Subject: | Re: [Caml-list] Co-existing with non OCaml threads |
Am Donnerstag, den 11.05.2006, 17:29 -0700 schrieb Francois Rouaix:
> I'm contemplating writing an OCaml interface for a C++ middleware
> library that my company develops and uses internally. Typically this
> middleware will start an event loop on a thread in the background,
> leaving the application responsible for its own threads (and
> potentially using none and having its own code running entirely on
> events within the eventloop thread).
> How's this likely to be compatible with OCaml use of native threads
> (this is on Linux by the way)?
> The manual section for interfacing with C isn't mentionning threads
> anywhere.
> Should Caml code be restricted to run on threads it has created? Or
> can it run on any threads?
> How can I synchronize between a thread running C++ code and a thread
> running OCaml code (i.e. both communicating on a message queue)?
> Thanks for any suggestions.
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()
When you call a C function that may block for indefinite time
one usually releases the lock first, calls the function, and
then requires it. The stub function looks like
value foo_stub (...) {
...
enter_blocking_section();
/* From here: NO ACCESS to any O'Caml memory, not even
* CAMLparam/CAMLlocal variables!
*/
...
foo();
...
leave_blocking_section();
/* Normal rules for stub functions apply again */
...
}
For callbacks from C code you will typically first call
leave_blocking_section() and later enter_blocking_section()
before you return.
- O'Caml must never see threads not created by itself. This
means a thread created by your middleware must not run
O'Caml code. (You get immediately a segfault if you try.)
- Although O'Caml mutexes and condition variables actually
base on their pthread counterparts, there is no interface
from the C side. So you better do any synchronization
completely in C, i.e. the message queue is written in C
and uses the normal pthread primitives. The O'Caml stub
functions accessing this queue need to call
enter/leave_blocking_section as explained.
Hope this helps. Had to solve a similar problem for a customer.
Gerd
--
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de
Phone: +49-6151-153855 Fax: +49-6151-997714
------------------------------------------------------------