Re: Hokay, I officially give up...
Mathieu Bouchard <matju-i8w/[email protected]> Fri, 22 May 2009 13:12:44 -0400 (EDT)
| Newsgroups | gmane.comp.programming.language-of-the-year |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 22 May 2009, Brian Hurt wrote: > Threading is definitely the challenge of this generation. > The real problem with multithreading bugs is that they are, basically by > definition, Heisenbugs. Literally, adding a debug print statement in some > unrelated part of the code changes the timing, and thus the behavior, of > the bug. Let alone things like changing the environment. If the problem > takes four days to replicate, this is unacceptable in a lot of > environments- but it's also a royal pain to track down and fix (been > there, done that). And things like unit tests don't help (the unit test > has been running a thousand times a second for the last three days, and > hasn't failed yet- can we declare it working yet? Um, no.). If your testing paradigm is unit-testing, and you'd like to keep it like that instead of trying to write mathematical proofs about your software, then does it sound like a good idea to try as much as possible to increase probability that the heisenbugs will jump in your face? That is, everywhere there are any potential sync problems, magnify them so that sync problems look increasingly bigger, likely, and basically unavoidable. Ok, easier said than done, but easier done than writing mathematical proofs about your software (and I mean getting the proofs right as well!). I suppose that the magnification would be done by introducing artificial delays in accessors, perhaps even artificial brittleness, e.g. try rereading the same variable 1000 times in a row and check that the result doesn't change while you try to do so, else raise an error, ... > Unfortunately, I think that multithreading is inevitable. The number of > cores is going to continue doubling every ~2 years, for the forseeable > future. Not only do we need to handle 2-, 4-, and 8- core machines, in > the not too distant future we'll need to handle 1024-core machines, or > 16,384-core machines. Actually, you don't even need to handle a 2-core machine, if your program doesn't actually need it nor benefit from it; it would be foolish to introduce a source of heisenbugs in a program that doesn't need to get any faster than what 1 cpu can offer. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec