I have not yet written thousands of line of parallel code in Clojure (I am in this learning curve as of now while experimenting with Terracotta). However I can compare with other frameworks I've used in the past: ASTs, Event Flags,... on VMS, semaphores, condition variables, mutexes, ... in libthread on various platforms, Java with its simplistic approach,...) and I fully agree with Rich.
There are always "simple shareable states" in any parallel system and you need an economical way to share these without requiring the full blown thing (taking a mutex before accessing/changing stuff, ....). Semaphores are a good example of state that can be shared and changed atomically with simple calls. Dig a bit and you will find them in many places. Having worked with a lot of real time systems I can guarantee that there are many spots where such mechanisms are a necessity. In java it's worse than in other language because many of these things have been hidden with "nice" keywords (synchronized, wait, ...). Other features have been dropped because people were killing their apps by lack of knowledge. Other features were not considered because they were not seen as required... yet. The implementation details in Java are so hidden to most people that there is seldom a discussion about the cost of using a specific feature and the impacts it has on parallelism. Parallel code is not mainstream yet in businesses aside from Swing code (:)), I hope Clojure will change that a lot), most coders do not deal with these issues very often or in a very superficial way. I expect this will have to change when parallel designs will become common. I would rather have more options than less to tune up my design and increase throughput... so atoms are welcomed. Luc >From a guy who's been doing a lot of multi threaded apps for more than twenty years (for those too young to remember, that was BEFORE libthread came to life :))) and yes I have grey hairs :))) On Wed, 2008-12-31 at 10:56 -0800, Rich Hickey wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
