5 ms·

concurrency stuff You're talking about at least 3 distinct models: direct thread management, with improved locking routines (java.util.concurrent, see recent P

by gtani 15y ago

concurrency stuff You're talking about at least 3 distinct models: direct thread management, with improved locking routines (java.util.concurrent, see recent Prismatic thread on HN), actors/green threads (Akka and erlang BEAM), and STM/guarded read/writes (clojure, and you should read about Microsoft's attempt to graft STM onto C#, Joe Duffy's blog)

jbooth 15y ago
java.util.concurrent's entire point is to make direct thread management unnecessary. Note the list of classes I mentioned didn't include Thread. Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff.
- dxbydt 15y ago
  >Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff. Its a mixed picture, if you want to be honest. There are places like bofa where I've pushed into production a cvar processing module on 500,000 loans which uses only actors. No low level tinkering with util.concurrent, no Threadpool setting, no Executors, no synchronized anywhere in my code. In the past at GS, I wrote concurrent code where I explicitly specified the number of threads & we had a ThreadPool manager & internally it used the util.concurrent classes. At LinkedIn, I believe they started with actors & switched parts of it to Doug Lea's framework ( which was the sort of the foundation of util.concurrent). I have seen financial shops where they do half & half - the quants seem to like actors but the swing programmers like to have control on threadcounts, & they tend to do things like naming threads & creating parent-child relationships so swing can paint reliably & they can debug threads by name when it doesn't. I did the same in the past when most of my work was on the swing side, creating custom blotters to show trade tickets & the like. But now I primarily do quant model building work with actors & no more util.concurrent stuff. If you want to construct a lattice model to price structured options on a 100 different strikes per month for 5 years in advance, you can find no better friend than an actor. Actors are certainly not a thought experiment, very much a reality.
  - jbooth 15y ago
    Great post, yeah I overstated a little bit and actors are certainly valid for certain cases. I was just reacting to what I saw as an overstatement on the other side.
- gruseom 15y ago
  You've made this point twice now ("Every serious project in Clojure or Scala that I've seen ignores their concurrency stuff and goes straight to Java") and I'm curious to hear some examples as well as your understanding of why this would be.
  - jbooth 15y ago
    For examples, the most recent ones I've seen are linkedin's kafka (scala), and bradford cross's recent post regarding clojure at prismatic (and other posts I've seen regarding both). For why, I'd assume that they found the abstractions were getting in their way. java.util.concurrent is sort of the minimum abstraction (IMO) between nicer constructs and OS-level threads.

by gtani 15y ago

jbooth 15y ago

java.util.concurrent's entire point is to make direct thread management unnecessary. Note the list of classes I mentioned didn't include Thread. Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff.

dxbydt 15y ago
>Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff. Its a mixed picture, if you want to be honest. There are places like bofa where I've pushed into production a cvar processing module on 500,000 loans which uses only actors. No low level tinkering with util.concurrent, no Threadpool setting, no Executors, no synchronized anywhere in my code. In the past at GS, I wrote concurrent code where I explicitly specified the number of threads & we had a ThreadPool manager & internally it used the util.concurrent classes. At LinkedIn, I believe they started with actors & switched parts of it to Doug Lea's framework ( which was the sort of the foundation of util.concurrent). I have seen financial shops where they do half & half - the quants seem to like actors but the swing programmers like to have control on threadcounts, & they tend to do things like naming threads & creating parent-child relationships so swing can paint reliably & they can debug threads by name when it doesn't. I did the same in the past when most of my work was on the swing side, creating custom blotters to show trade tickets & the like. But now I primarily do quant model building work with actors & no more util.concurrent stuff. If you want to construct a lattice model to price structured options on a 100 different strikes per month for 5 years in advance, you can find no better friend than an actor. Actors are certainly not a thought experiment, very much a reality.
- jbooth 15y ago
  Great post, yeah I overstated a little bit and actors are certainly valid for certain cases. I was just reacting to what I saw as an overstatement on the other side.
gruseom 15y ago
You've made this point twice now ("Every serious project in Clojure or Scala that I've seen ignores their concurrency stuff and goes straight to Java") and I'm curious to hear some examples as well as your understanding of why this would be.
- jbooth 15y ago
  For examples, the most recent ones I've seen are linkedin's kafka (scala), and bradford cross's recent post regarding clojure at prismatic (and other posts I've seen regarding both). For why, I'd assume that they found the abstractions were getting in their way. java.util.concurrent is sort of the minimum abstraction (IMO) between nicer constructs and OS-level threads.