Thanks. I think the problem was I was assuming somehow I could keep track
of my individual structures by some sort of object reference, independent of
their position in the world - woolly object-oriented thinking - which was
confusing me.
If I instead have a key (or query function) that finds a structure in the
world, then I can use option (c) in my original post - I'll have a ref for
the world, then @world will be a map of key to refs to my actual structures
-
(def world (ref {}))
(defn do_something_to [key something]
(dosync
(let [struct_ref (@world key)]
(if struct_ref
(alter struct_ref something)))))
If I understand correctly, two threads calling do_something_to with
different keys won't collide, as they read @world but don't change it. I'll
get a collision if one thread changes @world and another changes an
individual structure - but I guess that's necessary, as the change might
have deleted the record with the key needed by the other thread.
I'm definitely finding this easier if I think of it in terms of storing
stuff in a database :)
- Korny
On Wed, Apr 1, 2009 at 10:58 PM, Rich Hickey <richhic...@gmail.com> wrote:
>
>
>
> On Apr 1, 5:46 am, Christophe Grand <christo...@cgrand.net> wrote:
> > Hello Korny,
> >
> > I share your questioning.
> >
> > On 1 avr, 06:57, Korny Sietsma <ko...@sietsma.com> wrote:
> >
> > > (A) one ref for the whole world - in which case how do I stop parallel
> > > changes to two unrelated structures in the world from causing
> transaction
> > > retries?
> >
> > In this case, I wonder whether to extend "ensure" so as to be able to
> > ensure an invariant over a ref would be a good idea.
> > eg:
> >
> > (ensure world f arg1 arg2) ; compute (f @world arg1 arg2)
> > ;....
> > (commute world g arg3 arg4) ; commute iff (f @world arg1 arg2) still
> > returns the same value.
> >
>
> Interesting - I'll think about it. Off the top of my head I'm
> concerned about the use of commute - it's not really commute if you
> need to ensure that something hasn't changed. Also, there will be a
> lot of pressure on the root, and need for history, even if the
> mechanism avoids retries. You would only consider this if the need to
> see the world as a single value dominated other concerns.
>
> Until then, I recommend option C. Korny really has two things here -
> the set (please, anything but list) of identities that constitutes the
> world, and those identities themselves.
>
> Rich
>
> >
>
--
Kornelis Sietsma korny at my surname dot com
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
