ファイティングデッドロック：ロック解除されたコールバックパターン

デッドロック状況

ウィキペディアでは、デッドロックの次の定義を提供しています。「デッドロック（Eng。Deadlock）-マルチタスク環境またはDBMSの状況。複数のプロセスが、これらのプロセス自体が占有するリソースを無限に待機している状態です。」



相互ロックは通常、本質的に動的です。それらの兆候は、ユーザーアクション、ネットワークサービスの可用性、ハードドライブのヘッドの位置、プリエンプティブマルチタスクを備えたシステムでのタスク切り替えなどの要因に依存します。



デッドロックの典型的な例：最初のスレッド（A）はミューテックスM1をキャプチャし、次にミューテックスM2をキャプチャします。 2番目のスレッド（B）はM2ミューテックスをキャプチャし、その後、M1ミューテックスをキャプチャします。 これら2つのストリームの相互ブロックは、次のように発生します。ストリームAはM1をキャプチャし、ストリームBはM2をキャプチャします。その後、両方のストリームが「拡大」されます。 ミューテックスをキャプチャしようとすると、両方のスレッドがブロックされます。



説明されている相互ロックは、両方のスレッドが1つのミューテックスを正確にキャプチャする時間がある場合にのみ発生します。 それ以外の場合、スレッドは実行を継続します。



この状況は、複雑なマルチスレッドシステムでは非常に一般的です。 原則として、参加者ミューテックスは互いに離れて（システムのさまざまなコンポーネントで）配置され、相互ブロックの参加者を識別することはかなり困難です。

実際のシステムの一般的な状況

上記のデッドロックが発生する特殊なケースの1つは次のとおりです。

• 特定のオブジェクト（ワーカー）は、別のスレッドで何らかのアクティビティを実行します。 Workerオブジェクトは、その存在の開始時にこのストリームを作成し、それ自体が破棄される前に完了します。
• フローアクティビティは、特定のアクションの周期的な繰り返しで構成されます（たとえば、ネットワークからのデータの受信）。
• これらの個々のアクションの結果は、関数またはコールバックインターフェイスを通じてコン​​シューマに提供されます。
• Workerオブジェクトの寿命のどの時点でも、新しい消費者が表示されるか、既存の消費者が表示されなくなる場合があります。 Workerオブジェクトは、コンシューマーのリストを保持し、コンシューマーを登録および削除するための機能（それぞれregisterCallbackおよびunregisterCallback）を提供します。
• コンシューマのリストは共有リソースです。Workerオブジェクトの内部ストリームはそれにアクセスできます。また、ストリームのコンテキストからregisterCallbackとunregisterCallbackを呼び出すコンシューマも同様です。
• コンシューマのリストは共有リソースであるため、Workerオブジェクトが所有するミューテックスを使用して保護されます。 ミューテックスがキャプチャされると、コンシューマのリストが変更されます。 ミューテックスがキャプチャされると、データはWorkerオブジェクトからコンシューマに転送されます。

上記の状況はなぜ危険なのですか？ Workerオブジェクトの開発段階では、開発者はコールバックインターフェイスを介してシステムのどの関数が呼び出されるかをまだ知りませんでした。 彼はインターフェイスの要件のみを作成しました。関数には、そのようなデータが送信されるためのパラメータが必要です。 そして、この未知の方向への挑戦は、キャプチャされたミューテックスによって行われます。



説明した画像にいくつかのタッチを追加するだけで十分です（これは複雑なシステムで発生することです）。

• Workerオブジェクトのいずれかのコンシューマー内で、mutex Mがキャプチャーされます（もちろん、その後のリリースで）。
• キャプチャされたMutex Mを持つ別のシステムオブジェクトは、自身をWorkerオブジェクトのコンシューマとして登録します。

それだけです デッドロックが発生する可能性がある状況が判明しました。 100％のケースでは発生しません（参加する各スレッドが1つのミューテックスのみをキャプチャするために特定のダイナミクスが必要です）。これにより、このようなエラーの検索が大幅に複雑になります。



以下は、この問題を解決する2つの方法です。

方法1：ロックの順序を変更する

Workerオブジェクトは、内部ミューテックスをロックおよびロック解除するための個別の機能を提供し、コンシューマーは次のように登録します。

1. 最初（事前に）、Workerオブジェクトの内部ミューテックスがロックされます。
2. その後、コンシューマはミューテックスMのキャプチャを必要とするアクションを実行します。
3. コンシューマーはWorkerオブジェクトに登録します。 Workerオブジェクト内の内部ミューテックスのキャプチャは実行されません。

この方法の欠点は明らかです。

• 各コンシューマーは、Workerオブジェクトを操作する前に予備的なアクションの負担があります。 プログラマー側のエラーの確率が増加します。
• これは常に可能なわけではありません。MutexMがWorkerオブジェクトへのポインターへの安全なアクセスを提供した場合はどうなりますか？
• 「ガッツアウト」はsimplyいだけです。

方法2：データをコンシューマーに送信するときにミューテックスをブロックしない

このメソッドは有望に聞こえます。mutexがブロックされていないときにWorkerオブジェクトの内部ストリームからコンシューマーへのデータ転送が発生した場合、Workerオブジェクトを操作するときに起こりうるすべての相互ロックが修正されます。



ミューテックスがキャプチャされないときにコールバックを作成しないのはなぜですか？ Workerオブジェクトストリームは、登録されたコンシューマーのリストを調べて、各コンシューマーのインターフェイス関数を呼び出す必要があるためです。 リストがミューテックスによって保護されておらず、このサイクル中にリストの内容が変更されると、誤ったメモリアクセスによりプログラムがループしたり、クラッシュしたりする可能性があります。



消費者のリストのコピーを作成して（コピーを作成するとき、ミューテックスを取得する）、コピーをループしませんか？ unregisterCallbackを呼び出した後、データが転送されないことを消費者に保証する必要があるためです。 コンシューマがデストラクタからunregisterCallbackを呼び出すと、このコンシューマのコールバックインターフェイスへの後続のデータ転送により、プログラムがクラッシュします。



したがって、私たちはほとんど決定に達しました：

• 登録されたコンシューマーのインターフェイスを呼び出す前にワーカーオブジェクトストリームは、コンシューマーのリストのコピーを作成する必要があります。 ミューテックスがキャプチャされるとコピーが作成され、コンシューマにデータを送信するために、ストリームはリストのコピーをループします。
• unregisterCallback呼び出しが完了した後、コンシューマにデータが送信されないようにする必要があります。 ストリームからコンシューマーへの呼び出しごとにコンシューマーリストのコピーが作成されるため、コンシューマーリストのコピーの通過中にunregisterCallbackが呼び出された場合、「遅延呼び出し」のリスクは1回だけ存在します。
• したがって、Workerオブジェクトストリームがコンシューマにデータを転送し、コンシューマのリストのコピーを処理するときの状態を何らかの方法で識別する必要があります。 ストリームがこの状態にあるときにunregisterCallbackが呼び出された場合、unregisterCallbackからの戻りは、コンシューマへのデータ転送が完了するまで遅延する必要があります。

これがターンキーソリューションです。 その実装には、もう1つの同期オブジェクトが必要です-「条件変数」（英語の条件変数）：

• Workerオブジェクトには次が含まれます。
  • 消費者のリスト。
  • ストリームが現在データをコンシューマに送信していることを示すフラグ。
  • 消費者のリストとフラグへのアクセスを制限するミューテックス。
  • unregisterCallbackを「間に合わない」と呼んだ消費者の期待と目覚めを整理するための条件変数。
• フラグは最初にfalseに初期化されます。
• registerCallbackはミューテックスをキャプチャし、リストにコンシューマを追加して、ミューテックスを解放します。
• 消費者へのデータ転送サイクルの前にストリームは次のアクションを実行します。
  • ミューテックスをキャプチャします。
  • 消費者のリストのコピーを作成します。 ストリームスタックにコピーが作成されます。
  • フラグをtrueに設定します。
  • ミューテックスを解放します。
• ストリームはデータを消費者に転送し、消費者リストのコピーのサイクルを通過します。 ミューテックスはキャプチャされませんが、フラグは設定されます。
• データをコンシューマに送信した後、ストリームは次のアクションを実行します。
  • ミューテックスをキャプチャします。
  • フラグをfalseにリセットします。
  • 条件変数を使用してすべての保留中のスレッドを起動します。
  • ミューテックスを解放します。
• および-最も興味深い-unregisterCallback：
  • ミューテックスをキャプチャします。
  • リストからコンシューマーを削除します。
  • フラグが設定されている限り、条件変数で待機します。 アトミックに、ミューテックスは待機状態への移行とともにリリースされ、ミューテックスは目覚めとともにアトミックにキャプチャされます。
  • ミューテックスを解放します。

重要な注意：コンシューマーによって実装されたコールバックインターフェイスからunregisterCallbackを呼び出すことができる場合、説明されているアルゴリズムはunregisterCallback内で100％フリーズします。 これは簡単に解決できます。unregisterCallbackがWorkerオブジェクトの内部スレッドのコンテキストで呼び出された場合、フラグを確認して条件変数が変化するのを待つ必要はありません。

Qtライブラリ同期ツールを使用した実装

ヘッダーファイル：

class ICallback { public: virtual void dataReady(QByteArray data) = 0; }; class Worker : public QThread { public: Worker(); void registerCallback(ICallback *callback); void unregisterCallback(ICallback *callback); protected: virtual void run(); private: QMutex _mutex; QWaitCondition _wait; bool _callingNow; QLinkedList<ICallback *> _callbacks; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実装：

 Worker::Worker() : QThread(), _mutex(QMutex::NonRecursive), _callingNow(false) { ... } void Worker::registerCallback(ICallback *callback) { QMutexLocker locker(&_mutex); _callbacks.append(callback); } void Worker::unregisterCallback(ICallback *callback) { QMutexLocker locker(&_mutex); _callbacks.removeOne(callback); if(QThread::currentThread()!=this) { while(_callingNow) _wait.wait(&_mutex); } } void Worker::run() { while(...) { QByteArray data; ... QLinkedList<ICallback *> callbacksCopy; _mutex.lock(); _callingNow=true; callbacksCopy=_callbacks; _mutex.unlock(); for(QLinkedList<Callback *>::const_iterator it=callbacksCopy.begin(); it!=callbacksCopy.end(); ++it) { (*it)->dataReady(data); } _mutex.lock(); _callingNow=false; _wait.wakeAll(); _mutex.unlock(); } }