Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Co-existing with non OCaml threads
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-05-12 (11:22)
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


  and you can release it by


  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 (...) {
     /* From here: NO ACCESS to any O'Caml memory, not even
      * CAMLparam/CAMLlocal variables!
     /* 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 Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
Phone: +49-6151-153855                  Fax: +49-6151-997714