Thanks for your replies - Meikel and Alex,

I considered using refs, but perhaps wrongly, came to the conclusion
that they were for coordinating multiple changes atomically within an
STM ? I figured that I only had one shared piece of state - current-
state (input and output are both effectively thread-local) and that an
atom would be far more efficient for my use case.

I didn't notice that compare-and-set! had been exposed - so, yes, I
could use this, but it would probably only be to roll my own swap!
variant that allowed me to return a tuple of [new-state output]....

So, am I just being awkward :-) - should I really be using refs/STM's
to achieve this ? or am I using a pattern peculiar to myself because
of some other wierd design decision that I have taken ? or have others
come across the same requirement and been similarly perplexed ?

thx

Jules


On May 17, 5:12 pm, ataggart <alex.tagg...@gmail.com> wrote:
> If you are not concerned about coordination, then why not just grab
> the value beforehand and use compare-and-set:
>
> (let [old @my-atom
>       new (my-fn arg)]
>   (compare-and-set! my-atom old new)
>   (do-stuff old new))
>
> On the other hand, if you are concerned about coordination between
> multiple threads changing the state, then don't use atoms; use refs.
>
> On May 17, 8:49 am, Jules <jules.gosn...@gmail.com> wrote:
>
>
>
> > Guys,
>
> > I have a hybrid Java/Clojure project.
>
> > I'm finding myself moving more and more of the concurrent code from
> > Java to Clojure - because it is so much simpler to code in Clojure
> > :-)...
>
> > ... but I am also finding that I have a recurring problem for which
> > Clojure only seems to have a partial solution.
>
> > The problem occurs in stateful objects when you receive an input and
> > need to both modify your state and generate and deliver some output.
>
> > I store my internal state in an atom and use swap! to update it,
> > passing in the input and a pure function which accepts the object's
> > current state and input and returns the object's new state.
>
> > The problem is that there is no clear mechanism for returning the
> > object's output from the same pure function.
>
> > At the moment, I am going with a solution whereby my object's state is
> > a variable length tuple e.g. [current-state & latest-output]. This
> > allows me to return both new state and output from the same swap! I
> > just have to agree with all other functions reading the state that
> > only e.g. current-state is relevant and latest-output can be ignored
> > by all except the caller of swap!, which actually processes/delivers
> > it, but this feels clumsy.
>
> > Am I missing something here or is there room for another member of the
> > swap! family which returns a tuple with a similar structure to mine,
> > but only uses the head of this tuple to reset the state of the
> > enclosing atom ?
>
> > Thanks for your time,
>
> > Jules
>
> > --
> > 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 
> > athttp://groups.google.com/group/clojure?hl=en
>
> --
> 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 
> athttp://groups.google.com/group/clojure?hl=en

-- 
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

Reply via email to