マルチスレッドプログラミングについて少し。 パート1.悪の同期かどうか

職場では、負荷の高いマルチスレッドサービスまたはマルチプロセスサービス（アプリケーション、Web、インデックスサーバー）を頻繁に処理する必要があります。

十分に興味深いが、時には恩知らずの仕事は、この経済全体を最適化することです。

顧客のニーズの高まりは、多くの場合、システムの鉄コンポーネントをより新しいものに単純に置き換えることができないことにかかっています。 コンピューターのパフォーマンス、ハードドライブとネットワークの読み取り/書き込み速度は、クライアントの要求よりも大幅に遅くなります。

クラスタノードの数を増やすのに役立つことはめったにありません（通常、システムは分散されています）。

多くの場合、プロファイラーを実行し、ボトルネックを探し、ソースコードに移動して、同僚が残した間違いを修正する必要があります。

同期に関連するいくつかの問題については、ここで説明します。 これはマルチスレッドプログラミングの入門コースではありません。読者がスレッドとコンテキストスイッチの概念に精通しており、ミューテックス、セマフォなどの用途を知っていることを前提としています。



「Hello world」よりも大きなものを設計するマルチスレッドの開発者にとって、完全に非同期のコードを作成することは非常に難しいことは明らかです。共通チャネルに何かを書いて、メモリ内の構造を変更する必要があります（たとえば、ハッシュテーブルツリーを回転させます）キューなどから

このようなアクセスを同期することにより、コードのいくつかの重要なセクションの同時実行を制限します。 通常、これは1つであり、まれに複数のスレッド（1ライター/ Nリーダーなど）です。

同期の必要性は否定できません。 過度の同期は非常に有害です。プログラムの一部は2つか3つのスレッドで多少スマートに動作します。



ただし、実際には、実行の同期が不十分であると、同じ結果になることがあることが示されています-システムはスティックしています。 これは、並行して実行されるコードに、たとえば、HDDへのアクセス（連続シーク）が含まれる場合、または複数の大きなメモリチャンクにアクセスする場合（たとえば、コンテキストスイッチでキャッシュを絶えずリセットする-CPUキャッシュが愚かに落ちる）に発生します。

セマフォを使用する

セマフォは、ReadWriteMutex構造を構築するためだけに発明されたのではありません。 セマフォは、並行して実行されるコードの一部でハードウェアの負荷を軽減するために使用できます。

原則として、コードをプロファイリングすることで簡単に見つけることができる多くの「スティック」を治すことができます-スレッドの数が増えると、個々の関数の実行時間が著しく増加し、他の関数は同じまたは同等の速度で動作します。



プロファイラーの3番目の問題では、 invCI_semaphore



セマフォがInvalidateIdx



メソッドの呼び出しにinvCI_semaphore



後、 InvalidateIdx



メソッドの実行時間、したがってInvalidateIdx



メソッドがどのように変化したかを確認できます。

 semaphore invCI_semaphore(config.InvCI_Count/* = 5*/); ... int InvalidateCacheIdx() { ... while (...) { cache.SearchL2Index(); invCI_semaphore++; while (cache.InvalidateIdx()) {}; invCI_semaphore--; } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セマフォを使用するこの方法は非常に単純であり、プロセスを完全に理解する必要はありませんが、 各ブロックのスレッドの最大数が戦闘（実稼働中、クライアントシステム上）で選択される可能性が高いなど、多くの欠点があります。よく食べます。 しかし、この最適化方法の大きな利点は、実行計画を変更せずに、サービス全体のスレッド数をすばやく増やすことができることです。 エンジン全体をほとんど変更することなく、ボトルネックで以前の値にいくつかのセマフォを配置するだけです。 私はセマフォを考えずに使用することを支持していませんが、一時的な解決策として（クライアントを安心させるため）、このメソッドを複数回使用して、後で「正しく」冷静にやり直し、ソースコードを掘り下げました。

優先順位を付ける

優先度は非常に便利なメカニズムであり、アプリケーションを「簡単に」明るくすることもできます。 たとえば、システムログが別のストリームに書き込まれ、その優先度を最小に下げると、ログレベルを下げることなくプロセスを大幅に「促進」できます。

たとえば、多くのスレッドを持つプールが異なる優先度のタスクを処理する場合、次のタイプの設計を使用できます。

 // before doing ... if ( thisThread.pool.count() > 1 && !(currentTaskType in (asap, immediately, now)) ) { thisThread.priority = 2 * thisThread.pool.priority; } else { thisThread.priority = 5 * thisThread.pool.priority; } // do current task ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同時に、ストリームの優先度は、このストリームが存在するプールだけでなく、プロセス全体で有効であることを理解する必要があります。注意して使用してください。

Divide et impera（分割統治）

多くの場合、コードを即座に実行する必要はありません-つまり 一部のアクションまたはタスクの一部を延期できます。 たとえば、ログの書き込み、訪問数のカウント、キャッシュのインデックスの再作成など。

同期コードを個別のタスクにハイライトし、後で実行する（たとえば、いわゆるバックグラウンドサービスを使用する）ことにより、実行速度を大幅に向上させることができます。 別のスレッド、スレッドプール、または別のRPCプロセス（WebServiceへの非同期呼び出しなど）である場合もあります。 当然、このタスクの呼び出し（キューイングなど）の時間コストは、実行自体のコストよりも小さくなければなりません。

別のLOGストリームの例：

 //      : int log(int level, ...) { if (level >= level2log) { logMutex.lock(); try { file.write(...); file.flush(); } finally { logMutex.release(); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 //  -  : int log(int level, ...) { if (level >= level2log) { // ,     : logQueue.mutex.lock(); logQueue.add(currentThread.id, ...); logQueue.mutex.release(); //  -worker' : logQueue.threadEvent.pulse(); } } // background-logging thread: int logThreadProc() { ... while (true) { //   -   /* 500 ms */    /* 10 */: if ( logQueue.count < config.LogMaxCount /* = 10 */ || (sleepTime = currentTime - lastTime) < config.LogLatency /* = 500 */) { logQueue.threadEvent.wait(config.LogLatency - sleepTime); continue; }; //        : logQueue.mutex.lock(); try { foreach (... in logQueue) { file.write(...); logQueue.delete(...); } } finally { logQueue.mutex.release(); } //    : file.flush(); //  : logQueue.threadEvent.wait(); lastTime = currentTime; } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような単純な設計により、ロギングのコストを大幅に削減し、コンテキスト切り替えの結果を削減できます。これは、実際には、 log



メソッドを使用するスレッドの数に依存しません。

ロギングに追加のロジックを掛けて、ログに直接書き込むストリームのみがロードされることを理解することが重要です。 つまり ログを好きなだけインテリジェントにすることができます-LogLatencyの概念を導入し、例として、何らかの種類のログアナライザー（fail2banなど）を追加するか、すべてのデバッグメッセージを保存して、エラーの場合にのみログに記録し、TIDごとにグループ化しますなど -これらはすべて、実際には残りのスレッドをロードしません。

さらに、最初の方法を使用する場合（メッセージはログファイルに直接同期的に書き込まれます）、スレッドはいわゆる「並列化」されます。 つまり 同期オブジェクト（ミューテックス、クリティカルセクション、待機イベント）が多くなり、コンテキストスイッチのコストが高くなるほど、これらのオブジェクトを通過するすべてのスレッドが順番に実行される可能性が高くなります。

つまり タスクのマルチスレッド実行の速度は、シングルスレッド実行の速度に近づくか、さらに悪化します。 ロック（）とリリース（）の間の時間を短縮すると、コードは一度に2方向に改善されます。スレッド自体で速くなり、プロセスの「並列化」の可能性が減少します。

イベントのキューを整理すると、追加のフローの作成に頼ることなく、同様の構成を作成できる場合があります。 たとえば、いくつかのアクションをキューに入れて、たとえば「アイドル時間」の間に、同じスレッドで順番に実行するようにします。

これは、TCLで簡単に説明できます。

 ##   /  ... ... ##  counter : set counter [db onecolumn {select cntr from accesslog where userid = $userid}] %>     <%= $counter %> ... <% ##   " access log" in background,    "update idle": after idle UpdateAccess $userid [clock seconds] ## . .... ## -    : proc UpdateAccess {userid lasttime} { db exec {update accesslog set cntr = cntr + 1, lastaccess = $lasttime where userid = $userid} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キュー、FIFO、LIFO、およびマルチスレッド

キュー、データプール、またはシリアルバッファーを整理することは難しいことではありませんが、マルチスレッドとその他の条件が同じ場合、LIFOキューを1番目の選択肢にする必要があることに留意する必要があります（もちろん、アクションのシーケンスが重要でない場合）。 LIFOとFIFOを結合またはグループ化できる場合があります（LIFO要素を小さなFIFOキューにするか、たとえば最後からバッファーを構築するなど）。 このような歪みの意味は、プロセッサキャッシュにあり、一部はメモリの仮想編成にあります。 つまり LIFOの最後の要素がまだプロセッサキャッシュにある確率は、同じ長さのFIFOの同じ要素の確率よりも比較にならないほど高いです。



実例-独自のメモリマネージャでは、同じサイズのフリーオブジェクトのプールからハッシュテーブルが編成されました（多くの場合、 malloc



/ free



と呼ばれ、これが行われる理由を知っています:)。 プールはFIFOの原則に従って編成されましたmymalloc



関数は、 myfree



関数によってプールに入れられる最初の要素を返しました。 開発者にFIFOを使用するように促した理由は、バナリティーの点まで単純です。一部の悪意のある「プログラマー」がmyfree



後にmyfree



オブジェクトを使用した場合、プログラムはおそらくより長く動作します。 LIFOに置き換えた後、メモリマネージャーを積極的に使用する武器庫（アプリケーションサーバー）全体で約30％高速化されました。

ReadWriteMutex

多くの場合、同期は、オブジェクトが変更された場合にのみ必要です。 たとえば、共有ファイルに書き込むとき、リストやハッシュテーブルの構造を変更するときなど。 同時に、原則として、これは1つのスレッドにのみ許可されており、多くの場合、読み取りスレッドでさえブロックされます（変更の終わりまでのエントリが完全に有効ではないため、ダーティー読み取りと例外によるプログラムクラッシュを除外するため）。

RW-mutexを使用してこのようなオブジェクトをロックすると、読み取りストリームが互いにブロックせず、レコードがロックされている場合にのみコードが完全に同期されます（1つのスレッドで実行されます）。

読み取り/書き込みミューテックスを使用する場合は、オブジェクトの読み取り方法を常に正確に把握しておく必要があります。読み取り中であっても、オブジェクトが変更される場合があるためです（たとえば、初期化中に内部キャッシュを構築する場合や書き込み後の再初期化中）。 この場合、理想的なAPIはブロックするコールバックを提供します。マルチスレッドの場合は単独でブロックします。RWミューテックスの使用の可能性については、すべての例外を除き、APIドキュメントで詳しく説明されています。 一部のRW-mutex実装では、リーダースレッド（場合によってはライタースレッド）の数を事前に知る必要があります（mutexに伝える）。 これは、書き込みロックの特定の実装によるものです（通常、セマフォが使用されます）。 これらの制限やその他の制限にもかかわらず、複数のリーダーストリームがある場合は、可能な限り、そのようなミューテックスで同期することをお勧めします。

ドキュメントを読んで、ソースコードを読んでください

特定のクラスまたはオブジェクトの背後に隠されているものの無理解、時には誤解の問題は、マルチスレッドアプリケーションで使用する場合に特に重要です。 これは、基本的な同期オブジェクトに特に当てはまります。 RW-mutexの不適切な使用の例によって、私が意味することを明確にしようとします。

私の同僚の一人は、かつてセマフォ上に構築された公正なRWミューテックスを使用していました。 彼は、リーダーストリームの数をRWMutexクラスに動的に転送するのが面倒で（静的に「可能な最大」値を500に設定）、ライターストリームに次のコードを記述しました。

 ... RWMutex mtx(500); ... mtx.lockWrite(); hashTab.add(...); mtx.releaseWrite(); ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、負荷が大きいと 、サーバーは大暴れし、休止状態に入りました。 問題は、彼が2つのミスを犯したことです-500の静的な値を取得し、そのようなRW-mutexがこの特定のプラットフォームでどのように動作するかを理解しませんでした。 なぜなら RW-mutexは公平になりました-次のようなコードが使用されました：

 void RWMutex::lockWrite() { writeMutex.lock(); for (register int i = 0; i < readersCount /*    500 */; i++) readSemaphore++; } void RWMutex::releaseWrite() { if (!f4read) writeMutex.release(); readSemaphore -= readersCount; if (f4read) writeMutex.release(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この設計では、 readSemaphore += readersCount



ではなく、 lockWrite



本体のループでreadSemaphore++



インクリメントを使用しているため、リーダーストリームとライターストリームの機会が等しくなります。 おそらく彼は、このRWMutexを構築するためのセマフォクラスが1つのクロスプラットフォームライブラリを使用していることを知らなかったため、この特定のプラットフォーム用に次のような単純なコードが生成されました。

 int Semaphore::operator ++() { mutex.lock(); if (sema++ > MaxFlowCount) flowMutex.lock(); mutex.release(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり hashTab



ハッシュテーブルに100個の値が追加され、複数のリーダースレッドによって同時に読み取られた場合、100 * 500のロックが発生しました（コンテキストの切り替えにより数ミリ秒が発生しました）。 このストーリーで最も興味深いのは、それがベースクラスRWSyncHashTableであり、コードのあらゆる場所で積極的に使用されていることです。

留意してください：一部のAPIコンストラクトは既に同期している場合があります。 場合によっては、オブジェクトのコンストラクターとデストラクタでさえあります。 この場合、追加の同期は多くの場合有害です。 これは、おterをバターで台無しにしたときだけです。

ソースを読んで、APIのドキュメントを見てください-そして、そのような間違いはあなたを迂回する可能性が高いです。

同期！=待機中

実行の同期は、プロセスが待機することだけを行うことを意味するものではありません。 最新のシステムのブロック方法は非常に柔軟であり、次の設計を行うことができます。

 static int mtx_locked = 0; //   - - ,  1 ? while ( mtx_locked || !mtx.lock(config.MaxWaitTime /*  1 ms */) ) { //    -  -  ...  ... processNextRequest(); } //   -  ... mtx_locked++; //  ... processInLock(); // unlock ... mtx_locked--; mtx.release();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この種のコードを使用すると、ミューテックスがロックされて就寝するのを待つのではなく、現時点で別のことをしようとすることができます。 同様の原則に基づいて、実装方法は少し異なりますが（コールバックまたはイベントの実行、トランザクションの待機ロック、スレッドキャッシュごとなど）、非同期プログラミングの概念がベースになっています。 この場合、非常に単純なルール「待たないでください」に従う必要があります。

この例は、コンテキストスイッチを回避または最小化するもう1つのトリックを示しています。これは静的変数mtx_locked



です。 この手法により、コードがブロックされmtx.lock



いることが事前にわかっている場合（ mtx_locked > 0



）、 mtx_locked > 0



を実行できなくなります。確実に知る必要はありません。他のことを行うだけです。



おそらく最初の部分（多くの手紙）を終える価値があります。 誰かのために私がどこかで重要な真実を書いたなら、悪からではなく、従順に私を許してください。 提案、希望、批判を歓迎します。

次のパートでは：

• デッドロック
• イベント 待機中の反応;
• データバンクの同期。
• システム全体の同期（クロスプロセス、クロスクラスター）
• 非同期プログラミング。
• 共有リソース
• ごみ、リソースの解放
• ストリーム監視、HeartBit
• プロファイリング
• あなたの願い