On Aug 27, 7:17 am, peter veentjer <alarmnum...@gmail.com> wrote:
> Hi Christian,
>
> On Jul 13, 10:37 am, Christian Vest Hansen <karmazi...@gmail.com>
> wrote:
>
> > I believe that DeuceSTM i primarily intended as a research platform
> > for Java STMs, hence the flexibility with pluggable algorithms.
>
> > Another Java STM is multiverse:http://code.google.com/p/multiverse/-
> > the focus here is on performance. Multiverse is based on MVCC, like
> > the Clojure STM.
>
> > Both of these STMs operates with the mindset that objects are mutable
> > by default, and tries to control this mutability. Whereas in the world
> > of Clojure we have mutable references pointing to immutable values. In
> > fact, the correctness of the Clojure STM depends on the objects
> > "stored" in the refs be immutable.
>
> Multiverse also provides a ref programming model.
>
> So you could say this:
>
> @AtomicObject
> class Person{
> private String name;
>
> public String getName(){return name;}
>
> public void setName(String newName){this.name = newName;}
>
> }
>
> Or using the ref programming model:
>
> class Person{
> private final Ref<String> name = new Ref<String>();
>
> public String getName(){return name.get();}
>
> public void setName(String newName){name.set(newName);}
>
> }
>
> If you have multiple fields and and a static language like Java,
> the first approach programs better.
>
> If a mutable reference is stores in the field the following things
> could happen:
> 1) the object is not an atomicobject and you are left on your own. For
> example a java.util.LinkedList stored in the ref.
> The advantage of allowing 'unsafe' objects to be stored in the stm, is
> that they can flow through the stm. Just like
> a normal mutable object can flow through a
> java.util.concurrent.BlockingQueue. But I'm certain that people are
> going
> to run into problems because they forget that the object is not
> managed. Time will tell :)
> 2) the object is an atomic object and it will be managed by the stm as
> well.
>
> So something like this is no problem:
>
> @AtomicObjec
> class Person{Sttring name;...}
>
> Ref<Person> parentRef = new Ref<Person>();
>
> In this case the parent reference will be managed by the stm, but also
> the content of the parent object itself.
>
> A few other questions:
>
> Does Clojure support the stm version of condition variables: retry and
> orelse?
>
No. I don't want to use transactions for workflow. I don't want
blocking transactions. I don't want read tracking.
> And since Clojure is using MVCC, does it also suffer from a broken
> serialized isolation
> level?http://pveentjer.wordpress.com/2008/10/04/breaking-oracle-serializable/
>
Clojure doesn't promise any "serialized isolation level". It provides
snapshot isolation, which is subject to write skew, as better
described here:
http://en.wikipedia.org/wiki/Snapshot_isolation
In order to prevent write skew, Clojure provides the 'ensure'
operation which can be used for reads to non-written refs that form
part of the integrity promise of a transaction, without incurring that
overhead all the time for reads that do not. I much prefer having this
fine-grained choice.
> And what kind of performance do you get with clojure?
>
I'll let other people answer that from their experience, but only say
that it is probably too general a question to be particularly
meaningful. Clojure's STM is part of a holistic language design where
people will normally be programming with immutable persistent
composite data structures. Getting a consistent view of such a data
structure doesn't require a transaction at all, so that is much faster
than other strategies. When 'changing' a data structure, you read it
from the ref once and then structural changes do not involve the STM
or refs. Store it back in the ref when done. Thus the granularity of
transactions is coarse and the number of ref interactions involved
small. These are not things you'll see when timing pounding an integer
in a transactional ref in a tight loop, but matter greatly in
practice, IMO.
Rich
> PS:
> I think that Clojure really did a great job with adding STM to the
> language. I have been working on multiverse for almost a year,
> and I only have an stm. With Clojure the STM is one of the many
> features provided.
>
>
>
> > On Mon, Jul 13, 2009 at 2:07 AM, Vagif Verdi<vagif.ve...@gmail.com> wrote:
>
> > > Potentially interesting library for clojurians. Java STM
> > > implementation:http://www.deucestm.org/
>
> > --
> > Venlig hilsen / Kind regards,
> > Christian Vest Hansen.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
