Getting concurrency

[Thomas Lindgren]

Someone just mentioned the following article (and I
managed to delete the original mail):

http://www.tbray.org/ongoing/When/200x/2005/06/12/Threads

Regarding Erlang, I think Bray is posing one question
and rebutting another. The question is, in essence,
will the mainstream ever "get" concurrency? In
particular, does Erlang hold the answer to how to get
it? His answer is, his "biggest programming wins have
been all about a bunch of threads running around a big
shared data structure", which Erlang avoids. Thus,
Erlang is not quite what's needed.

But that objection seems to be about performance first
of all, not about quality. Nontrivial use of shared
datastructures _is_ quite difficult to work with,
regarding correctness, resilience, scalability, and
performance. If you want the foot soldiers to get it
right on a regular basis, going at it on the level of
threads and locks is thus probably the wrong approach.

(A more promising approach in the "shared data for the
masses paradigm", IMO, is to use transactions
pervasively. And yes, I'll admit it: that approach is
not ready to deploy tomorrow :-)

On the other hand, can we then claim that message
passing without shared state is The Answer? As most
experienced Erlang programmers know, ets and mnesia
tend to show up after a while, so at the logical level
shared state is still with us. The real answer (if
there indeed is any "the" answer to be found) is
somewhere in between (and Erlang/OTP is not
necessarily the ideal trade-off). 

However, even with this caveat, I would still claim
that message passing, when applicable, is easier to
work with, safer to use, and transfers to a
distributed setting more easily, when compared to
threads and shared state -- so, as a starting point,
it makes good sense.

Best,
Thomas



		
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html