On 5 March 2010 17:56, Mark Engelberg <mark.engelb...@gmail.com> wrote:
>
> On Wed, Mar 3, 2010 at 5:20 PM, Rick Moynihan <rick.moyni...@gmail.com>
> wrote:
>>
>> If you have a single value representing the whole world, then it seems
>> that protecting it with an atom would be the simplest and most
>> idiomatic solution.
>
>> For a single value there seems to be little reason to adopt refs, ...
>
> I disagree.  The problem with atoms is that updating an atom is a
> side-effect that cannot (typically) participate safely in a transaction.  It
> might be retried, so if for example, you want to increment the contents of
> an atom, it might get incremented multiple times which is generally not okay
> (if you're storing something in a cache, then a retry might be okay).
>
> If you make a design decision to use an atom, you are effectively committing
> to never, ever being able to update that atom within a transaction.

This is a good point, one that I hadn't considered and arguably also
non-obvious!  Though all is not necessarily lost when state you don't
control is held in an atom, as you can wrap it inside an agent which
will be co-ordinated with the STM, ensuring safe modification in the
event of retries.

> refs can do everything atoms can do and more.  They are slightly slower, 
> perhaps, but much safer.  So
> unless you have an explicit performance reason to use atoms and have thought 
> through the
> implications, the simplest design choice is to prefer refs.

My simple (uncontended) tests seem to indicate that atoms are about 4x
faster than refs (though I'd love to see a more comprehensive
benchmark).  Regardless I'll certainly be more cautious about using
atoms in the future, as refs are without doubt more composable.

R.

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