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