Raimo Niskanen P?P8QP5Q:
On Wed, May 05, 2010 at 01:37:17PM +0300, Stas Miasnikou wrote:
Tony Abernethy wrote:
Lars Nooden wrote:
On Wed, 5 May 2010, Geoff wrote:
There's a paper from Berkeley showing how a threaded program can
never be fully debugged and should be presumed to be broken,
probably fatally broken.
Geoff, can you post the URL or any details that might help finding and
retrieving that particular article or ones like it?

/Lars
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
first choice googling: threads berkeley

Choice quote: (quoting Sutter and Laurs)
"humans are quicly overwhelmed by concurrency and find it much more
difficult to reason about concurrent than sequential code. Even careful
people miss possible interleavings among even simple collections of
partially ordered operations."
Some people, when confronted with a problem, think "I know, I'll use multithreading." Now they have N problems.
        --(almost) jwz

Time for a shameless plug for my favourite programming language:
Erlang <http://www.erlang.org>.

By using such a language you avoid thinking about interleaving
code totally, since (almost) all interactions between processes are
in the form of explicit messages sent and received. You have no
shared data and no locks (for the Erlang programmer).

I find much easier to get a grip on a concurrent problem thinking
in these terms which is familiar for the human brain since all
humans act this way (message passing and no shared data).

The virtual machine that executes all these lightweight
virtual processes will take the battle with the locks
and the VM programmers are probably doomed to hunt bugs
until the end of days, but that reduces the problem
to getting it right enough for one program only (the VM),
not for every program every programmer writes.

Pity for you localization of the problem != solution of the problem.

Other than some stunts with data binding I don't think I've seen
anything that is competent to handle partial orders. And that one breaks
down horribly if storage cells take on more than one value during execution.

                                        Stas

Reply via email to