Hi Rick/java-threads, > I went to the Scala Exchange in London this week. Concurrency is a big deal > in Scala. The received wisdom is that everything has to be non-blocking > because threads are a scarce resource. This is often justifiable, > occasionally not (example case > history<http://www.bigbeeconsultants.co.uk/blog/dispatch-http-critique> > ). > > I decided to write some thoughts up why on this and why it's unfortunate in > my latest blog<http://www.bigbeeconsultants.co.uk/blog/wrestling-with-concurrency-at-scala-exchange-2012>. > It's interesting to contrast Go, which is at ease with concurrency and > enthusiastically advocates it, against Scala, where it is seen as something > of an expert topic. > > I'm also interested in Akka, which is now (from v2.10) the standard Scala > actor library. In particular, it appears to offer a subset of CSP - each > actor is like a CSProcess containing a while(true) loop; each process has *only > one* input channel, which is always a shared channel with infinite > buffering. The channel doesn't have any identity outside of its actor; > clients write to the channel, but use the name of the actor to do so. > > So I have a question: would it be possible for a pluggable bundle of input > channels on Akka actors so that the model would become more general? (The > default behaviour would remain the single Any2One channel with infinite > buffering.) It would be necessary to introduce Alternative and the other > types of channel currently available in JCSP (for example), and this > shouldn't itself be too hard. > > But Akka also provides remoting, therefore it would be necessary for the > channels to automatically pick up their networked configuration via > existing Akka techniques. > > I'm no expert on Akka so this is a bit outside my comfort zone. Anyone care > to enlighten me further? I probably can't enlighten any more on Scala, knowing very little about it, but the headroom of 30 threads seems daft -- presumably they're talking about some machine which is potentially running lots of these things, so talking about <= 1000 OS threads (divided amongst JVM instances). Some of it probably depends on what JVM you're using. Obviously if the JVM has user-level [green] thread-scheduling, number of threads is not much of an issue, but the dynamic stack allocation for these may be (roll on 64-bit memory addressing). Also garbage collecting across large numbers of threads is potentially resource consuming, depending again on what JVM and collector it is using. The Akka approach sounds very much like the Erlang approach, where the Actor model is one of the few sensible approaches. I take some issue with this though -- it strikes me that the [Actor] model is used because it happens to fit with the underlying concurrent execution model (which is what has happened with Erlang from my limited viewpoint). And as a result, all high-level programming problems get transformed into Actor-based things, and when that doesn't go well, or doesn't even fit well to start with, people start thinking that "concurrency is hard" and similar things. It's probably safe to say that we can take any Actor system and implement it as a CSP-style system (perhaps with pi-calculus flavoured dynamics as you have in JCSP, JCSP.net and occam-pi) -- simple, just use an AnyToOne channel, or equivalent shared channel bundles in occam-pi. However, the other way around doesn't work so cleanly; the Actor model is only good for problems that fit; it's not a general solution to concurrent programming. My 2p worth :) -- Fred
Attachment:
pgp4dpwQwpb1K.pgp
Description: PGP signature