Hi,
Richard Jones < rich%40annexia.org">rich
annexia.org> 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
.
