"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. > -- 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.
