C# 4.0によるデッドロックの問題の「解決」

作者 David West , 翻訳者 編集部 投稿日 2009年3月18日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

.NET ,

コンパイラ ,

プログラミング

タグ

Code Generation ,

Multi-threading ,

設計ガイドライン

同じソースコードの最適化されたビルドと最適化されていないビルドは、それぞれ異なるデッドロックになる可能性がある(リンク)ことを、数年前、Eric Lippert氏は述べた。C#の4.0リリースで問題は「解決」した(リンク)。「解決」はカギ括弧でくくられている。なぜならその解決法にはそれ独自の問題が 伴っているからである。

もともとの問題は、最適化やデバッグをオン/オフに選択した方法に基づき、一貫しない方法で機械コードにILを変換する場合に、コンパイラが何もしないという命令を挿入する可能性があることから生じた。Lippert氏は以下のように述べた。

Recall that lock(obj){body} was a syntactic sugar for

var temp = obj;
Monitor.Enter(temp);
try { body }
finally { Monitor.Exit(temp); }

ここでの問題は、モニタの入力とtry-protected領域に何もしないという命令をコンパイラが生成した場合、ランタイムがモニタの入力後で、かつトライの前にスレッド異常終了例外をスローする可能性があるということである。そのシナリオでは、最終的には実行しないので、ロックがリークし、おそらく結果的にはプログラムがデッドロックする。最適化されていないビルドおよび最適化されたビルドにおいて、これが起こり得なければ良い。

しかしながら、ソリューションには独自の問題がある。Eric氏によると「一貫して悪い。それは一貫性なく悪いよりはましである。しかし、このcodegenに潜在する大きな問題は、デッドロックしたプログラムは起こり得る中で最悪だという考えである。それは必ずしも真実ではない。

ロックの目的は、変わりやすいリソースを保護する、または別の言い方をすれば、変わりやすいリソースの複数のユーザが、リソースの破損したバージョンにアクセスすることから保護することである。現在の4.0ソリューションには元の状態へのロールバックや変化の完了の保証はない。ロックステートメントの最終 節に分岐させる例外を発生させることができる。それによりロックを解放し、あらゆる待機スレッドに対するアクセスを許可する。ソリューションは、結果の一貫性の矛盾を生み、デッドロックの可能性を減らす。この問題は特に、マルチスレッドプログラミングでは危険である。

この具体的な矛盾には、2つの悪い結果という選択が関わる。プログラムのデッドロックか重要なリソース状態の保護の失敗である。しかしこの具体的な例は、設計上の決定の1つであり、マルチスレッドプログラミングをする場合に強制される矛盾である。

この種の設計上の問題はマルチスレッドに特異のものではなく、「ロックセーフ」と「例外セーフ」の間には違いがあることを多くのデベロッパが述べている(リンク)。 Lippert氏は、マルチスレッドは難しい問題をさらに難しくするだけであり「正しくロックすることだけが第一歩である」ので、他のすべての例外を処理し、どのように処理されるのかを検討する必要があると語った。多くの回答者がスレッドのアボートの危険性を指摘し、Lippert氏が語る「スレッドの異常終了は悪である」ということに大方同意している。

 

原文はこちらです：http://www.infoq.com/news/2009/03/CSharpDeadlockFixed

• 次へ >