[ANN] STMlib: an experimental STM library for OCaml is available
- Hi there,
I'd like to announce the availability of an user-space implementation of STM
library for OCaml. The library is still in its alpha stage, and currently has
just one back-end (for threads). You're welcome to try it and send
feedback. Bugs report and suggestions will be appreciated.
The address is http://www.pps.jussieu.fr/~li/software/index.html#stmlib ,
where you can find all the sources, examples and documents.
Here is some paragraphs from the README:
This is a user-space implementation of STM (Software Transactional Memory)
library for OCaml. It's mainly inspired by the STM library of Haskell (you may
want to read some of the references in the REFERENCE section), with some
exceptions due to the different nature of languages and the different
strategies of implementation.
- This library is a user level implementation, whereas the Haskell version is
based on primitives built into the runtime.
- This library is purely an add-on to the already existed concurrent library
of standard OCaml: threads, processes (TODO) and network programs
(TODO). I.e. you can still program your concurrent applications with all
facilities already exist in OCaml (such as Thread.create or Unix.fork to
launch new thread/process respectively), but with the functions from this
library you may transactionally read/write shared data instead of using
locks or messages (and you may mix them if you really want).
- There are subtle differences on the signatures and semantics of some
specific functions between this library and the Haskell version. They are
documented in the library manual.
Currently only the threads back-end is provided as a proof of concept. Other
back-ends, which share the exact interface, will come out some time later. With
the help of iThread module (a minimal common interface for launching and
manipulating threads/process/network programs with uniformed functions, having
a naive implemented and not publicly available at this moment), you will be
able to write a single program (.ml) and compile once (.cmo), but link with
different backends to get different excutables based on different execution
model (threaded, multi-process and networked).
The following literature is helpful on understanding STM. The first one is
especially recommended from a programmer's (library user) point of view.
- Beautiful concurrency: a practical illustration of STM
- STM paper: rigorous semantics definition of STM in Haskell
- Haskell wiki page on STM
- On Fri, Mar 02, 2007 at 06:23:55AM +0100, LI Zheng wrote:
> Currently only the threads back-end is provided as a proof ofDoes the current backend try and clever execution strategies
> concept. Other back-ends, which share the exact interface, will come
> out some time later. With the help of iThread module (a minimal
> common interface for launching and manipulating
> threads/process/network programs with uniformed functions, having a
> naive implemented and not publicly available at this moment), you
> will be able to write a single program (.ml) and compile once
> (.cmo), but link with different backends to get different excutables
> based on different execution model (threaded, multi-process and
(eg. speculatively executing transactions)?
Do you plan to support something like MPI?
Also, I think there is a typo in your documentation:
val atom : 'a stm -> 'a
This is an analog of automatically in Haskell, [...]
should 'automatically' be 'atomically'?
Red Hat UK Limited
Richard Jones <rich@...> writes:
> Does the current backend try and clever execution strategiesNot yet, there is just one thread back-end at this moment.
> (eg. speculatively executing transactions)?
More accurately, there is no _clever_ strategies here but just a plain one:
command line. I.e., compile your source against a single common interface, but
decide which implementation to use at linking time. e.g.
$ ocamlc -c -I +stm your_module.ml
$ ocamlc -o app.thread -I +stm/threads -other-option stm.cmo your_module.cmo
$ ocamlc -o app.process -I +stm/process -other-option stm.cmo your_module.cmo
At this moment, you can test it with threads/vmthreads, as they are always of
the same source: both the STM library itself and your program.
The advantages of shared interface here are more than just Makefile issues:
- you have only one version of source,
* without changing "Unix.fork" to "Thread.create" (here we needs help
from iThread) and various other adaptions between different execution
* without changing back-end module deployment in any kind of forms such as
module qualifier (everywhere)
ProcessStm.tvar ----> ThreadsStm.tvar
or cleverer (one line per file)
module S = ProcessStm ----> module S = ThreadsStm
or similar (one line per file)
open ProcessStm ----> open ThreadsStm
or if we using functor (one line per file)
module S = Stm.Make(Stm.Process) --->
module S = Stm.Make(Stm.Threads)
in order to get different versions of source file for each execution
- you can distribute your own module (if they depend on the Stm module) in a
uniform format, i.e. a single version of your_module.cmo instead of
your_module_threads.cmo your_module_process.cmo etc, and the programmers
using your module can also uniformly program/compile theirs in the same way.
Until the time of linking, the final application builder can still choose
freely which backend to use, or simply produce all the versions based on
If what you mean is a clever strategy to choose back-ends at _running_ time
other than _linking_ time, this involves 1) pack all the backend together,
ensure all their prerequisites do not conflict (not the case for
threads/vmthreads/process) 2) use module as first-class value, which is
unfortunately impossible in OCaml (maybe possible by playing some tricks with
bytecode mode? )
Finally, I should again remind all interested user: you don't have to mess with
these back-ends switching stuff if you don't care. You can just use it in the
plain traditional way as any (vm)threads-related module, just use a fixed
directory path e.g. -I +stm/threads, or simply copy the stm.mli and stm.ml
anywhere and compile as usual.
> Do you plan to support something like MPI?The current road map is threads -> process -> network program (on plain
sockets). Yes, it's possible to have a MPI back-end or design the network
back-end cleverly to take MPI compatibility into consideration.
> Also, I think there is a typo in your documentation:Yes! Thanks for point out. I've update the documents, with other minor
> val atom : 'a stm -> 'a
> This is an analog of automatically in Haskell, [...]
> should 'automatically' be 'atomically'?