Referring to http://clojure.org/refs :
Rule 1. states that all your reads will be consistent as of the starting
point of the transaction
Rule 2. states that no changes will have been made by any other transactions
to any Refs that have been *ref-set**/altered**/ensured* by this
transaction.
So by
Hmm - I'm unclear. I had the impression that if thread a *reads* ref
"world" and thread b *alters* ref "world" that would cause one of them to
retry... is that wrong? It probably doesn't matter to my code, but it'd be
good to know.
- Korny
On Thu, Apr 2, 2009 at 6:11 PM, Laurent PETIT wrote:
>
Hello,
2009/4/2 Korny Sietsma
>
> 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 n
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 s
On Apr 1, 6:57 am, Korny Sietsma wrote:
> I have a world that is a list of structures
>
> The world itself will change occasionally - i.e. I'll add or remove
> structures from the overall list, and I'll regularly be reading the whole
> list.
> (C) both of the above - a ref for the "world" list w
On Apr 1, 5:46 am, Christophe Grand wrote:
> Hello Korny,
>
> I share your questioning.
>
> On 1 avr, 06:57, Korny Sietsma 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
> > retri
Hello Korny,
I share your questioning.
On 1 avr, 06:57, Korny Sietsma 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 t
I came across a thread from Jul '08 which seems to be the definitive
on handling side-effects within transactions -
http://groups.google.co.za/group/clojure/browse_thread/thread/d645d77a8b51f01/667e833c1ea381d7
Adrian.
On Wed, Apr 1, 2009 at 9:24 AM, Timothy Pratley
wrote:
>
> Hi Korny,
>
>
> T
Hi Korny,
That is a very interesting question to me, specifically this part:
> how do I stop parallel
> changes to two unrelated structures in the world from causing transaction
> retries?
Actually I don't think you can ever rule out retries if you are using
a ref (or atom) and more than one t
Hi - I'm struggling with what is probably a very basic STM problem... so
forgive me if I've missed something obvious.
I have a world that is a list of structures
The world itself will change occasionally - i.e. I'll add or remove
structures from the overall list, and I'll regularly be reading the
10 matches
Mail list logo
