Re: The problem(s) with threads

[Rick Beton <rick.beton@xxxxxxxxx>]

On 7 January 2011 07:21, Teig, Oyvind              UTCFS
<Oyvind.Teig@xxxxxxxxxxxxxxxx> wrote:
> I don't mean to plague this group with my blogs, but this may be quite
> relevant:
> http://oyvteig.blogspot.com/2010/12/021-problems-with-threads.html
> Besides, there may be an error or two that might need correction?
> (Lee has applauded the initiative)


Thanks for posting this Oyvind. On a minor matter, there is a
misspelling of "alternation" without the first 'n', which therefore
gives the wrong meaning of course ("alteration").

I am interested in what you have written and also, going beyond that,
in the actor model.  The key messages (to me) of your posting are
these:

* The non-compositional thread model of concurrency based on shared
locks is known to be hard to use.  Java epitomises this.  CSP
processes provide a compositional way of dealing with concurrency that
forces programmers to deal with concurrency but makes it much easier
to do so.

* Received wisdom is that anything missing from a language can
suitably be provided via a library. Different languages achieve
varying success in this regard.  Your article hints that libraries and
design patterns may only go some of the way to helping programmers
deal with concurrency.  The suggestion is that better static (and,
potentially, runtime) analysis might be achieved if suitable
concurrency primitives are built into the language.

On this latter point, I take some issue with Scala.  Its developers
have adopted the actor model.  I think this is a shame because it's
easy to imitate the actor model upon CSP but rather inefficient to do
the reverse.  So it would have been much better had they adopted the
CSP model intrinsically within the language and provided actors upon
it, either via a library or possibly within the language.

I suspect that CSP sits uneasily in the mind of many functional
programming advocates.  In FP, one objective is to use declarative
programming to gain implicit concurrency without needing it to be
explicit.  CSP of course is all about explicit concurrency and
therefore is anathema to such a mindset.  Scala has pretentions to be
an FP language, yet it is really imperative, and still provides
explicit concurrency in the form of actors.  Hence my qualms about
Scala not including CSP - if explicit concurrency is really necessary
(and I think it is in imperative languages), then CSP is arguably a
better basis than actors.

Regards,
Rick Beton