Thanks for taking to time for such a detailed explanation Rich. This makes things much clear. And thanks Chouser for the pictorial representation.
Parth On Dec 5, 6:24 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote: > > > Are there any screencasts planned which will feature atoms? (I found > > that the screencasts are an excellent way of learning clojure). > > Screencasts are generally a side-effect of a speaking engagement. I > imagine next time I give a talk, I'll talk about atoms too. > > To address the general question about when to use atoms/refs/agents, > it helps to think of things this way: > > First, note that in talking about atoms/refs/agents we are talking > about Clojure's reference types that allow changes to be seen by > multiple threads, so these three reference types are all shared > reference types. > > There are two dimensions to the choice about using them, the first is > - will the changes be synchronous or asynchronous, and the second is, > will a change to this reference ever need to be coordinated with a > change to another reference or references. > > Chouser made a nice diagram after I described this on IRC: > > http://clojure.googlegroups.com/web/clojure-conc.png > > As you can see, for coordinated changes, refs + transactions are the > only game in town, and asynchrony (beyond a set of commutes) doesn't > make much sense, so no reference type is coming to replace the X. > > For independent change, you have two choices, agents and atoms. > > Atoms are synchronous, the change happens on the calling thread. They > are as close to a plain variable as you get from Clojure, with a > critical benefit - they are thread safe, in particular, they are not > subject to read-modify-write race conditions. Your writes don't happen > unless they are a function of what was read. But modifications to > atoms are side effects, and thus need to be avoided in transactions. > > Agents are asynchronous, and that can have important benefits. In > particular, it means actions get queued, and the sender can proceed > immediately. They provide a transparent interface to the threading > system and thread pools. Agents also cooperate with transactions in > ways that atoms cannot - e.g. agent sends are allowed in transactions > and get held until commit. > > What's nice is the unified model underlying the reference types. All > can be read via deref/@, all are designed to refer to an immutable > data value, and to model change as a function of that value. All > support validators. > > What that means is that, if you build your state transformation > functions as pure functions, you can freely choose/switch between the > different reference types, even using the same logic for two different > reference types. > > However, they are different, and they have not been unified in the > areas in which they differ, in particular, they each have a unique > modification vocabulary - ref-set/alter/commute/send/send-off/swap!/ > compare-and-set!. > > In the end, Clojure is a tool, and will never be able to make > architectural decisions for you. Hopefully the above will help you > make informed choices. > > The memoization example is a prime motivating case for atoms - a local > cache. It's also one that people routinely get multithread-wrong when > trying to implement with simple mutable variables. > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
