Scala STM

[Ian Clarke]

In case people haven't seen it, Daniel Spiewak has a series of blog
entries explaining how to implement STM in Scala:

http://www.codecommit.com/blog/scala/software-transactional-memory-in-scala

While our requirements are somewhat more demanding (atomic blocks
potentially executing across multiple machines), this should serve as
inspiration at a minimum.

Ian.

--
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588

[Patrick Wright]

We might want to take a look at existing STM libraries for Java

Distributed STM
http://proglang.informatik.uni-freiburg.de/projects/syncstm/
http://code.google.com/p/tazio/
http://www.xstm.net/

Regular STM
http://web.ist.utl.pt/~joao.cachopo/jvstm/
http://code.google.com/p/multiverse/
http://code.google.com/p/deuce/
http://code.google.com/p/quickstem/

Darkstar-oriented STM
http://code.google.com/p/mnemoj/

I can't say anything about the state or quality of these libraries.

Patrick

[Patrick Wright]

Actually, we shouldn't forget Clojure's STM. That's most likely the
one getting the most attention (and workout) right now.

[Neil]

I briefly looked over that article, and it looks pretty promising from
what I can see. The big boon with tacking our STM onto another system
is that we get automatic support from them for bugs in their code. The
only difference between the STM we require, and the one proposed in
the article Ian posted is that we would require a distributed locking
mechanism to gain a commit lock, and that we would also require a
mechanism to get access to resources on other resources (the talk of
another article though).

The good thing is that we could quickly get a fully working STM system
working within Swarm, simply by doing the changes I say above, but not
necessarily the most efficient one (if we have instead of a commit
lock, a distributed proposal/agreement system for instance).

I definitely think it would be worth integrating Swarm into other
systems.

-Neil.

[Rick R]

I could see an STM concept working well with the Temporal Optimistic Locking concepts that Bayani mentioned.

More concretely, an object would declare that a series of both reads and writes to be atomic. The atomic read and write would be necessary to guarantee causality in case of a conflict. If a write was successful, then the updates are broadcast to all readers of the object. If a conflict does occur, then the rules of optimistic CC come into play.

http://en.wikipedia.org/wiki/Optimistic_concurrency_control

This method avoids having to muck about with all of those messages required to lock an object. But of course can slow things down if an object is being frequently written. Perhaps if the user expects conflict, he can optimize things by acquiring an explicit lock.

[rektide]

Thanks for the link dump Patrick; I expect it'll lead to some good
reading.

Rick Richardson mentioned Akka as perhaps the "go to" actor model for
swarm. Akka's actors are actually transactors[1], "transactional
actors", which are actors based around STM, in this case based around
Multiverse STM[2], which you've already cited. Leveraging the
existing Akka base would be a smart move, if Akka/Multiverse provide a
sufficient base.

[1] http://wiki.github.com/jboner/akka/reference-software-transactional-memory-stm
[2] http://code.google.com/p/multiverse/

[rektide]

To quote extensively from the Akka STM link[1]:

> Akka’s STM implements the concept in Clojure’s STM view on state
> in general. Please take the time to read this excellent document[3] and
> view this presentation[4] by Rich Hickey (the genius behind Clojure),
> since it forms the basis of Akka’s view on STM and state in general.

> It is based on two concepts:
> Persistent Datastructures: Immutable but with constant time access
> and modification. The use structural sharing and and an insert or update
> does not ruin the old structure, hence “persistent”.
> Managed References: Memory cells, holding an immutable value, that
> implement CAS (Compare-And-Swap) semantics and are managed
> and enforced by the STM for coordinated changes across many References.

> The Persistent Datastructures consists of a Map and Vector and are Scala
> ports of Clojure’s Map and Vector.
> The Managed References are implemented using the excellent Multiverse STM[2].

[3] http://clojure.org/state
[4] http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

On Oct 30, 5:19 pm, rektide <rekt...@gmail.com> wrote:
>
> Rick Richardson mentioned Akka as perhaps the "go to" actor model for
> swarm.  Akka's actors are actually transactors[1], "transactional
> actors", which are actors based around STM, in this case based around
> Multiverse STM[2], which you've already cited.  Leveraging the
> existing Akka base would be a smart move, if Akka/Multiverse provide a
> sufficient base.
>

> [1] http://wiki.github.com/jboner/akka/reference-software-transactional-m...
> [2] http://code.google.com/p/multiverse/