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. > > >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 -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
