D. Richard Hipp today on the SQLite mailing list:
I am constantly amazed at the prevailing idea (exemplified
by Java) that software should be strongly typed and should
not use goto statement or pointers - all in the name of
reducing bugs - but that it is OK to use multiple threads
within the same address space. Strong typing helps prevent
only bugs that are trivially easy to locate and fix. The
use of goto statements and pointers likewise results in
deterministic problems that are easy to test for and
relatively easy to track down and correct. But threading
bugs tend to manifest themselves as timing-dependent
glitches and lock-ups that are hardware and platform
dependent, that never happen the same way twice, and that
only appear for customers after deployment and never in a
testing environment.
1 Kommentare:
The quote is true, but incomplete. Strong typing and lack of goto statements are techniques to minimize certain classes of bugs... and they are effective. However, consider how many security problems are caused by failure to check boundaries of a structure or an array: strong typing avoids certain problems for ARRAY of 1..N but not the case of trying access the N+1st unit of the array.
The solution to the bounds-checking problem thus lies elsewhere. It can be explicit (programmed in tediously), implicit (added by the compiler for each/every array access, thereby inflating the code and destroying efficiency), or something in-between (run-time environment memory access violation traps, etc.). Personally, I prefer the first, but it depends on programmers' having the skill to pick the right places to do it and the time in tight development schedules to implement it. And, frankly, we all know that programmers would rather not add such tedium to otherwise elegant code.
Thread bugs are similar. The keys are re-entrance and synchronization. These may be explicit, implicit, or in-between. However, here we find that many fewer programmers have the skills to do this explicitly: aside from OS hacks, the vast majority of programmers have not had to deal with these issues for decades due to the prevailing single-core, single-thread paradigm. Compilers generally handle re-entrance fairly well -- although not always perfectly -- but sync continues to elude them.
That all changed in 2005, about the time you posted the original blog, with the advent of mass market game processors, especially the 3-core, 6-thread processor in Xbox360 and (with Linux available for it) the 9-core, 10-thread Cell B.E. processor in PS3. Sites like Mike Acton's CellPerformance.com give a lot tips, especially for those who program down to the metal.
One would hope that programming environments will catch up, now that x86 multicore is prevalent. Now 5 years after your initial post, what tools do you know that automatically detect races and other conflicts for multi-threaded programs?
Post a Comment