why concurrency in the first place?

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

why concurrency in the first place?

Sean Hinde-2
> Hello,
> I know this may sound like a naieve question but I would like
> to have a
> thorough answer any way :)
> "Why does an (Erlang) programmer have to program his application with
> concurrency explicitly in mind?"
> I also know (think) that this was the main intention of the Erlang
> language.

Concurrency is useful in the classic sense of making a multithreaded
transaction or event based system which does not completely grind to a halt
if a single transaction is very slow to finish.

It is also useful where one has an application where many different tasks
can continue in a loosely arranged way. For example one may want to have a
global logging process which other parts of the system can simply fire
messages into and then get on with what they were doing without waiting.
(I'm sure there are many other better examples out there)

Concurrency also provides a very natural way to express timeouts in an
application. A process can send itself a message some time later to remind
it to check on something while it gets on with handling other tasks.

Message passing is also used for all I/O in Erlang (including transparent
message passing to a process on another physical node)

As you say message passing and processes are to all intents and purposes the
only source of impurity in Erlang, and IMHO are much simpler to comrehend
and more flexible than Monads (I see there are moves to introduce
asynchronous exceptions, explicit concurrency, message passing and timers
into Haskell which I must say don't look all that "beautiful". All these
things were needed to produce a working Haskell HTTP server. See
http://research.microsoft.com/Users/simonpj/ for a very interesting
collection of papers).

The message passing model of Erlang also provides a nice mechanism to
decompose a large application into distinct sub applications with very clean
APIs and interfaces between them.

If you look through some of the source of the OTP system you will see many
beautiful examples of the craft of Erlang programming and use of spawn and
message passing. Particularly the MNESIA database system uses these concepts
to incredible effect - many complex transactions can happen in parallel
across different machines and still a user application can get real time
access to any data.

With regards to your point about whether a compiler can deduce the
concurrency requirements of an application from a pure specification I doubt
it at the moment. Certainly Haskell doesn't appear to do anything other than
provide primitive support for concurrency in prototype versions.

If only Erlang had something like the extraordinary type system of Haskell

- Sean

This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.