Week nine has been the heaviest week for manual analysis. Although certain types of changes, such as stylistic refactoring, are easy to pinpoint and classify, there are certain categories of change that are quite hard to detect and require a lot of rooting through different versions of code. For example, the changes due to race conditions or other under-synchronization are difficult to classify because they often require me to sort through the entire rest of the file outside of the diff content and determine where the blocking or signaling thread that's causing the race condition is located. Since we want this analysis of the 60 randomly sampled changes to be very comprehensive, I am spending a lot of time on writing detailed explanations so that Professor Lu can refer to them as her lab moves into writing condition variable synchronization algorithms in the future.
Something I've found interesting in doing my analysis has been the relatively high number of changes related to adding abstraction and increasing code reusability. It appears that more changes are related to following good coding practices than correcting actual correctness problems. I believe this constant effort to adhere to good development practice might account for the relatively low number of correctness issues encountered (at least in regards to condition variable synchronization). I am going to write about this a little bit in my final paper, because I think it'll be interesting to compare Apache to another project which maybe does not rely so heavily on abstraction and special reusable structures. I would be curious to see if another project maybe requires more correctness fixes if they do less refactoring for performance and abstraction and code reusability.
At the end of the week, I began writing up the spreadsheet of the findings of my manual study. It's hard to organize this into something readable but containing enough information about each individual change. Since Professor Lu will be using my results in her future papers to justify the decisions her lab will make when creating certain multithreaded development tools, I would like to make sure my findings are as clearly explained and organized as possible, but this is proving challenging. She has met with me once this week to review what I've come up with so far and she has made some helpful suggestions so in the next week I hope to come up with final results that follow all her specifications and will be very helpful in the future.
Something I've found interesting in doing my analysis has been the relatively high number of changes related to adding abstraction and increasing code reusability. It appears that more changes are related to following good coding practices than correcting actual correctness problems. I believe this constant effort to adhere to good development practice might account for the relatively low number of correctness issues encountered (at least in regards to condition variable synchronization). I am going to write about this a little bit in my final paper, because I think it'll be interesting to compare Apache to another project which maybe does not rely so heavily on abstraction and special reusable structures. I would be curious to see if another project maybe requires more correctness fixes if they do less refactoring for performance and abstraction and code reusability.
At the end of the week, I began writing up the spreadsheet of the findings of my manual study. It's hard to organize this into something readable but containing enough information about each individual change. Since Professor Lu will be using my results in her future papers to justify the decisions her lab will make when creating certain multithreaded development tools, I would like to make sure my findings are as clearly explained and organized as possible, but this is proving challenging. She has met with me once this week to review what I've come up with so far and she has made some helpful suggestions so in the next week I hope to come up with final results that follow all her specifications and will be very helpful in the future.