[論文レビュー] Automatically finding atomic regions for fixing bugs in Concurrent programs

Saurabh Joshi, Akash Lal|arXiv (Cornell University)|Mar 7, 2014

Parallel Computing and Optimization Techniques参考文献 15被引用数 3

ひとこと要約

この論文では、ユーザーが提供するアサーションと検証ツールを活用して、並行バグを修正する最小限のアトミック領域を自動的に推論するAtomicInfという手法を提示する。検証ツールを用いて最小のストロングアトミックな修正と最適化されたウィークアトミックな拡張を効率的に計算し、過去の手法よりも平均1.7倍速く、正しさを保ちつつ最大限の並行性を実現する。

ABSTRACT

This paper presents a technique for automatically constructing a fix for buggy concurrent programs: given a concurrent program that does not satisfy user-provided assertions, we infer atomic blocks that fix the program. An atomic block protects a piece of code and ensures that it runs without interruption from other threads. Our technique uses a verification tool as a subroutine to find the smallest atomic regions that remove all bugs in a given program. Keeping the atomic regions small allows for maximum concurrency. We have implemented our approach in a tool called AtomicInf. A user of AtomicInf can choose between strong and weak atomicity semantics for the inferred fix. While the former is simpler to find, the latter provides more information about the bugs that got fixed. We ran AtomicInf on several benchmarks and came up with the smallest and the most precise atomic regions in all of them. We implemented an earlier technique to our setting and observed that AtomicInf is 1.7 times faster on an average as compared to an earlier approach.

研究の動機と目的

• 並行バグの意味のある最小限の修正を自動生成する課題に取り組むこと。
• 修正が正しく動作するプログラムの振る舞いをすべて保持し、バグの原因となるインタリーブィングのみを排除すること。
• アトミックブロックのサイズを最小限に抑えて並行性を最大化し、パフォーマンスの低下を回避すること。
• ストロングアトミックティとウィークアトミックティの両方の意味論をサポートし、ウィークアトミックティがバグの根本原因をより深く理解する手がかりを提供すること。
• データレースなどの症状に依存せず、ユーザー定義の性質に焦点を当てた、スケーラブルで検証駆動のアプローチを開発すること。

提案手法

• 並行プログラムにおけるバグの原因となるトレースを繰り返し発見するために、検証ツール（例：Poirot）をサブルーチンとして使用する。
• 二段階のアプローチを採用：まずアルゴリズム1を用いてストロングアトミックティ下での最小の修正を計算し、次にアルゴリズム2と3を用いてウィークアトミックティ下で拡張する。
• ウィークアトミックティの場合、計算コストを削減しながら最小性を保つために、ストロングアトミックティの修正のスーパーセットに制限して探索を制限する。
• すべてのバグのトレースをブロックする最小のプログラムポイントの集合を特定するために、最小ヒッティングセット（MHS）計算を採用する。
• ユーザーがストロングアトミックティとウィークアトミックティの意味論のどちらを選ぶかを可能にし、ストロングアトミックティはブロック全体の隔離を保証し、ウィークアトミックティは他のウィークブロックの並行実行を許容する。
• 市販の検証ツールと統合し、反復的精錬によって高価な検証クエリの回数を最小限に抑える。

実験結果

リサーチクエスチョン

• RQ1 並行プログラムにおけるすべてのアサーション違反を修正する最小のアトミック領域を自動的に推論できるか？
• RQ2 推論された修正がすべての正しいプログラムの振る舞いを保持し、新たなバグを導入しないことをどのように保証できるか？
• RQ3 修正の品質と計算コストの観点から、ストロングアトミックティとウィークアトミックティの意味論の間でどのようなトレードオフがあるか？
• RQ4 最小限で正確な修正を依然として見つけることができる状態で、高価な検証クエリの数を減らすことは可能か？
• RQ5 データレースやアトミックティ違反のヒューリスティクスに依存する従来のアプローチと比較して、提案手法のパフォーマンスと修正品質はどのように異なるか？

主な発見

• AtomicInfは、テストしたすべてのベンチマークで最小かつ最も正確なアトミック領域を計算し、修正品質において従来手法を上回った。
• 平均してAtomicInfは以前の手法よりも1.7倍速く、アルゴリズム2はクエリ数と実行時間をアルゴリズム1と比較して顕著に削減した。
• ストロングアトミックティの場合、アルゴリズム1と2は同じ最小の修正に収束するが、アルゴリズム2は平均でクエリ数を20%削減し、実行時間を74%短縮した。
• ウィークアトミックティの探索をストロングアトミックティの修正のスーパーセットに制限する最適化は、修正品質を保持し、過剰な計算を回避するが、解のサイズにほとんど影響を与えない。
• すべてのベンチマークで、計算された修正は手動での検証により正しくかつ最小限であることが確認され、不要なプログラムポイントは含まれなかった。
• 異常値のベンチマークであるBankAccountでは、アルゴリズム1は平均でアルゴリズム2の2倍のクエリ数を要した。これは、最適化されたアプローチによるスケーラビリティの向上を示している。