On Dec 31, 1:20 pm, "Mark Engelberg" <mark.engelb...@gmail.com> wrote:
> On Wed, Dec 31, 2008 at 6:27 AM, Rich Hickey <richhic...@gmail.com> wrote:
> > I also think that your use cases for atoms for local mutation are a
> > mismatch. atoms are about sharing. You really want something else for
> > private/local mutable references, and I have some ideas for that.
>
> My impression so far of atoms is that they are "underpowered", and
> suitable for a very small set of use cases, most of which you could
> have already done with refs and commute (albeit with a slight
> performance penalty). Since atoms are side-effecting, their
> composability with other transaction-based Clojure code is limited.
I wish you would stop repeating that. I've give you concrete use cases
where atoms might be essential to good scalability in a transactional
context, lest every transaction that uses a memoized function or ID
generator have to serialize on it.
Their compatibility with transactions can be completely irrelevant for
non-transactional subsystems where atoms can form a useful substrate
for lock-free synchronous state.
And, in subsystems using transactions, all effort must be applied to
keeping transactions small, and most code out of them. Using atoms can
help enable that where refs are not necessary.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
