On Mon, Dec 22, 2008 at 4:23 AM, Parth Malwankar
<parth.malwan...@gmail.com> wrote:
> If I get it right, atoms are quite useful to maintain state
> in the context of a single thread with memoization and
> counter (within a thread) being two examples.
No, RH said that atoms were definitely intended for multiple threads,
not just single threads. But their use is highly specific. With
memoization, it doesn't matter if things get retried, as long as
things don't get "lost". atom basically guarantees that the ref and
the set occur atomically (via swap), so you don't have to worry about
two threads losing something from the cache as follows:
Current cache {:a 1 :b 2}
One thread tries to add :c 3, and another tries to add :d 4.
Without atomic swap, one thread could try to update the cache to {:a 1
:b 2 :c 3} and the other to {:a 1 :b 2 :d 4} (because they are both
basing their updates on what they see). Whichever one wins, one of
the values will be "lost" from the cache.)
So atoms make this one guarantee, allowing safe multithread
memoization, but at great risk for other types of applications,
because most "seemingly-obvious" uses for atoms would probably be
hosed by the possible retry.
I fear a lot of people are going to end up misusing atoms. I assume
they were necessary to make memoization perform better than under the
ref-with-commute approach.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
