Loading ...
Sorry, an error occurred while loading the content.
 

[ANN] STMlib: an experimental STM library for OCaml is available

Expand Messages
  • LI Zheng
    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
    Message 1 of 3 , Mar 1, 2007
      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.

      best regards
      - li


      Here is some paragraphs from the README:

      -----------------------------------------------------------------------------

      DESCRIPTION
      ===========


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



      REFERENCE
      =========

      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
      <http://research.microsoft.com/~simonpj/papers/stm/#beautiful>

      - STM paper: rigorous semantics definition of STM in Haskell
      <http://research.microsoft.com/~simonpj/papers/stm/#composble>

      - Haskell wiki page on STM
      <http://www.haskell.org/haskellwiki/Software_transactional_memory>
    • Richard Jones
      ... Does the current backend try and clever execution strategies (eg. speculatively executing transactions)? Do you plan to support something like MPI? Also, I
      Message 2 of 3 , Mar 3, 2007
        On Fri, Mar 02, 2007 at 06:23:55AM +0100, LI Zheng wrote:
        > 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).

        Does the current backend try and clever execution strategies
        (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'?

        Rich.

        --
        Richard Jones
        Red Hat UK Limited
      • Zheng Li
        Hi, ... Not yet, there is just one thread back-end at this moment. More accurately, there is no _clever_ strategies here but just a plain one: command line.
        Message 3 of 3 , Mar 3, 2007
          Hi,

          Richard Jones <rich@...> writes:
          > Does the current backend try and clever execution strategies
          > (eg. speculatively executing transactions)?
          Not yet, there is just one thread back-end at this moment.

          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
          models

          * 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
          model

          - 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
          all back-ends.

          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:
          >
          > val atom : 'a stm -> 'a
          > This is an analog of automatically in Haskell, [...]
          >
          > should 'automatically' be 'atomically'?
          Yes! Thanks for point out. I've update the documents, with other minor
          corrections.


          - li
        Your message has been successfully submitted and would be delivered to recipients shortly.