I've worked with, and debugged, code written in several different concurrency paradigms:
- Data-flow - Asynchronous / Futures / Continuation Passing - Actors - Software-Transactional memory - Shared state with locks & mutexes - Fork-Join and my experience mirrors Ricky's, shared state is by far the hardest to reason about. By comparison, STM is probably the easiest to understand, Asynchronous is the best performing, and Actors the most reliable. Data-flow and fork-join aren't truly general purpose techniques, which makes them hard to categorise in this fashion. Shared state *can* have a performance benefit, the LMAX disruptor shows this clearly. But it also demonstrates the performance benefit of avoiding locks - which can easily harm performance much more than GC pressure. This is the same reason that the asynchronous model also performs so well, even in the presence of immutable objects. On 23 July 2012 17:01, Ricky Clarkson <ricky.clark...@gmail.com> wrote: > "I claim that understanding errors that arise because of multithreaded > mutable code is really not that difficult." > > My experience is entirely the opposite. I found it very difficult to work > out what the original programmer intended to happen in what order in code > like that, to fix problems without introducing new ones. > > PropertyChangeListener spaghetti monsters are real. > > On Mon, Jul 23, 2012 at 12:25 PM, Cédric Beust ♔ <ced...@beust.com> wrote: > >> >> On Mon, Jul 23, 2012 at 3:07 AM, Russel Winder <rus...@winder.org.uk>wrote: >> >>> java.concurrent.util is showing more and more high-level features as >>> Doug et al. work them in, but the problem remains that most Java >>> programmers still think shared-memory multi-threading is the way to code >>> up parallel algorithms. >>> >> >> To be fair, there is nothing running on the JVM today showing that this >> is wrong. All the alternate solutions fail on one of these criteria while >> java.concurrent.util meets them all: >> >> - Proven track record of scaling to very high loads and used in many, >> many very high traffic sites (starting with Google). And by that, I don't >> just mean that "company X says they are using language Y", which means >> very >> little, but that this code actually powers the monumental traffic that >> these sites support. >> >> - Performance coming directly from the mutable aspect. A lot of the >> immutable approaches to concurrency will use, by definition, more memory >> and generate more garbage collector pressure, which is often the bottle >> neck in these high load applications. >> >> - Easy to reason about. Yes, I claim that understanding errors that >> arise because of multithreaded mutable code is really not that difficult. >> It's also easy to solve (albeit admittedly harder to solve optimally). >> Alternatives offered by actors or asynchronous solutions don't have some >> problems that mutable code has but they certainly have plenty others >> (starting by the difficulty of tracing fully asynchronous code to create a >> reproducible test case). >> >> - Very mature and powerful tools. Eclipse will even show you who >> holds a lock to what in the stack frame. >> >> java.concurrent.util has set the bar very high and so far, I remain >> unconvinced that any other technology is even close to being able to >> perform as well on all these criteria. >> >> -- >> Cédric >> >> -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
