[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scala-Exchange - Concurrency is a Big Deal in Scala

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