Adding my two cents: I'd say immutablity, transactions/refs, futures, and actors. I'd also talk a lot about what I call the "four horsemen of the parallel apocalypse"- race conditions, deadlocks, live locks, and priority inversions. These are all bugs that, while they *can* show up in senquential code, show up a heck of a lot more often, and are bigger problems, in parallel code. They are also all "heisenbugs", in that they are all timing dependent, so "inconsequential" changes in other parts of the code can change the expression of, or even hide, the bug. And they are not amenable for classic testing or debugging strategies to handle. Any mutable value needs to come with an iron clad guarantee that either a) that value is only ever accessed from a single thread, or b) that the code is properly synchronized when it accesses that variable. Any thing else will simply lead to tears and recriminations.
Thus the importance of immutability as a default for most objects- immutable objects don't need to be synchronized on. Transactions and refs come with guarantees of synchronization correctness, as do actors. So to do atoms, but in a less rigorous, and more error prone, way. Futures and actors are two ways to express parallelism. For the record, I agree with SPJ- I don't think there is one right way to express parallelism. Brian On Wed, Aug 1, 2012 at 8:29 PM, Brian Marick <mar...@exampler.com> wrote: > I'm writing a book on /Functional Programming for the Object-Oriented > Programmer/. <https://leanpub.com/fp-oo> It uses Clojure as the teaching > language. > > Since one of the things that attracts programmers to FP is the hope that > ordinary mortals can write multicore programs, I want to have a chapter on > concurrency. Of the various types of concurrency Clojure offers, which do > you think would be most useful to explain? My inclination is: > auto-concurrency due to immutability, futures (I love futures), and atoms. > What do you think would be the right set? > > ----- > Brian Marick, Artisanal Labrador > Contract programming in Ruby and Clojure > Occasional consulting on Agile > > > -- > 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 > -- 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
