Getting concurrency

[Jouni Rynö]

One should note, that author also writes:

<Quote start>
Problem: Testing and Debugging I am right now, in the Zeppelin 
context, grinding away on a highly concurrent multi-threaded 
application. Debugging it is a complete mindfuck, and I’m 
spending too much time debugging it because I have no idea how to 
write the unit tests. Consider a method that gets a network request 
for more resources, discovers which other computers in the cluster are 
advertising cycles to spare, pings them to see if they’re really 
there, asks them to handle the request, and reports back to the 
requester; how do you unit-test that? I have no idea. ¶

This is hard low-level Computer Science and we in the industry 
trenches could sure use some help from the researchers; are the 
researchers looking in this direction?
<Quote end>

So even if one could easily write multi-threaded applications, do they 
work and how do prove it :)

Jouni

On Tue, 14 Jun 2005 03:48:30 -0700 (PDT)
  Thomas Lindgren <thomasl_erlang@REDACTED> wrote:
> 
> 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 
>