I think the funniest moment in this entire paper was the accurate yet obvious statement that if it takes a large amount of time to locate a bug in a program it will take a longer time to fix the bug. I understand the direction that this statement is heading towards: that concurrency bugs can be maddening to locate, and if it takes years to find them, it may take years just to correctly reproduce the conditions they occur under, and therefore it will take even more time to figure out how to protect against that condition. It is a very important point, as these concurrency issues are extremely important to solve before concurrency becomes standard.
What I find interesting is the approach of a lite-data retention in the first passes to build an outline of where the problems lie. I remember a previous paper where we were using technical abilities to predict areas of conflict in concurrency. This seems like a great possibility for combination of tools in order to better produce techniques for correct development. Again it seems that we have a great idea, with good technical setup and a good tool base, but since it succeeds at its own aims the authors haven't looked beyond to create a stronger technique for us to use to solve these complex problems with greater efficacy.
No comments:
Post a Comment