OmniThreadLibraryライブラリ-Delphi環境でのシンプルなマルチスレッド

技術的なトピックに関する興味深い記事を書くことは非常に困難です。 技術的なジャングルに滑り込まないことと、何も言わないことのバランスを取る必要があります。 今日は、Delphi環境でのマルチスレッドデスクトップアプリケーションの開発の現状について（詳細なしで）一般的な用語で話そうとします。これは、今日ではあまり一般的ではありませんが、多くのロシアの開発者によく知られています。 この記事では、プログラミングの初心者ではなく、マルチスレッドアプリケーションを作成する分野に初めて焦点を当てています。





タイトルでカバーされているトピックは非常に広範囲です。 以下に書かれているのは氷山の一角すらではなく、これらの氷山が浮かぶ海抜10,000メートルの高度での飛行です。 なぜそのような記事を書くのですか？ むしろ、長い間利用可能であったが、何らかの理由で多くが恐れて恥ずかしがり屋である広い機会に注意を払うために。

デルファイを選ぶ理由

私は非常に長い間Delphiでプログラミングしてきましたが、それを楽しむのをやめません。 それは多くの点で素晴​​らしい言語です。 その独自性は、同時に「ハードウェアに近い」ままで、任意の高レベルのコードを作成できるという事実にあります。 出力は、Javaまたは.Net仮想マシンのコードではなく、ネイティブアプリケーションです。 同時に、Delphi言語は非常にシンプルで簡潔で、コードは読みやすく、理解しやすいため、CまたはC ++のコードについては言えません（Cの開発者に敬意を表しますが、これは単なる習慣の問題です）。

現時点では、Delphiは以前の人気を失っています。 これはおそらく、2000年代にこの製品が開発者によって数年間ほとんど放棄され、その結果、しばらくの間、開発環境の競争の激しい競争から脱落したという事実のために起こりました。 実際、2002年にボーランドによってリリースされたDelphi 7の後、多かれ少なかれ安定した製品が2007年にのみ登場しました。 これは、ボーランドの子会社であるCodeGearがリリースしたCodeGear Delphi 2007でした。 Delphi 7とDelphi 2007の間のすべてのバージョンは、実際には使用できませんでした。 2008年、BorlandはCodeGear部門をEmbarcadero Technologiesに売却しました。EmbarcaderoTechnologiesは（彼女に感謝します！）すぐに、彼女が手に入れたものを最新の高品質な開発環境に変え始めました。 執筆時点でのDelphiの現在のバージョンは、2011年9月にリリースされたEmbarcadero Delphi XE2です。 最新のDelphiバージョンはかなり高品質であるため、この開発環境は失われたポジションを徐々に取り戻しています。

なぜマルチスレッドが必要なのですか？

人々は、コンピューター上で同時にいくつかのタスクを実行したいと考えていました。 これはマルチタスクと呼ばれます。 マルチタスクは、オペレーティングシステムによって実装されます。 ただし、OSが複数のアプリケーションを同時に実行できる場合、一度に複数のタスクを実行するために、内部の1つのアプリケーションも実行しないようにしましょう。 たとえば、大量のファイルのリストをアーカイブする場合、アーカイバは、メモリ内の次のファイルを同時に読み取り、現在の読み取りをアーカイブし、ディスク上の出力ファイルに結果を書き込むことができます。 つまり 1つのストリームの各ファイルで「読み取り」->「アーカイブ」->「ディスクに結果を書き込む」の代わりに、3つのストリームを開始できます。1つはファイルをメモリに読み取り、2つ目のストリームはアーカイブされます。 3番目はディスクに保存することです。 別の例は、いくつかの優先度の低いタスクのバックグラウンドでのパフォーマンスです。たとえば、テキストエディターで開いたファイルのバックアップコピーをバックグラウンドで保存します。

プロセッサが90年代から2000年代初期と同じペースでクロック速度を上げ続けた場合、マルチスレッドに煩わされず、従来のシングルスレッドコードを書き続ける必要はありません。 ただし、近年、プロセッサは1つのコアの速度を積極的に上げることをやめましたが、これらのコア自体の数を増やし始めました。 最新のプロセッサの可能性を100％使用するには、マルチスレッドが不可欠です。

マルチスレッドコードを書くのが難しいのはなぜですか？

1）間違いを犯しやすい。

複数のアプリケーションがコンピューター上で同時に実行されている場合、各プロセスのアドレス空間（メモリ）はオペレーティングシステムによって他のプロセスから確実に分離され、他の誰かのアドレス空間に入ることは非常に困難です。 反対に、同じプロセス内のスレッドでは、それらはすべてプロセスの共通ア​​ドレス空間で動作し、任意に変更できます。 そのため、マルチスレッドアプリケーションでは、メモリ保護とスレッド同期を個別に実装する必要があります。これにより、比較的複雑であると同時にペイロードコードを運ばないようにする必要が生じます。 このコードは、「ボイラープレート」（フライパン）と呼ばれます。パンを調理する前に、まずパンを調理する必要があるためです。 マルチスレッドコンピューティングの開発を妨げる「非標準」ボイラープレートコードを記述する必要があります。 スレッドを同期するための特別なメカニズムが多数あります。インターロックされたプロセッサ命令、オペレーティングシステム同期のオブジェクト（クリティカルセクション、ミューテックス、セマフォ、イベントなど）、スピンロックなど。

2）マルチスレッドアプリケーションのコードは分析が困難です。

マルチスレッドアプリケーションの難点の1つは、特定のメソッドを異なるスレッドから呼び出す（または呼び出す）ことができるかどうかをマルチスレッドアプリケーションのコードで見ると視覚的に明確でないことです。 つまり 異なるスレッドから呼び出すことができるメソッドと呼び出せないメソッドを覚えておく必要があります。 絶対にすべてのメソッドをスレッドセーフにすることはオプションではないため、複数のスレッドからスレッドセーフでないメソッドを呼び出すと、常にエラーが発生する可能性があります。

3）マルチスレッドアプリケーションはデバッグが困難です。

マルチスレッドアプリケーションでは、スレッドの特定の状態が並行して実行されている場合（原則として、一連のコマンドが異なるスレッドで実行された場合）、多くのエラーが発生する可能性があります。 興味深い例をここで説明します（http://www.thedelphigeek.com/2011/08/multithreading-is-hard.html）。 このような状況を人為的に作成することは、多くの場合非常に難しく、ほとんど不可能です。 さらに、Delphiにはマルチスレッドアプリケーションをデバッグするためのツールはあまり多くありませんが、Visual Studioはこの点で明確なリーダーです。

4）マルチスレッドアプリケーションでは、エラーを処理することは困難です。

アプリケーションにグラフィカルユーザーインターフェイスがある場合、1つのスレッドのみがユーザーと対話できます。 通常、アプリケーションで何らかのエラーが発生した場合、アプリケーション内でエラーを処理するか、ユーザーにメッセージを表示します。 追加のストリームでエラーが発生した場合、「すぐに」ユーザーに何も言えません。 したがって、メインストリームと同期するまで追加のストリームで発生したエラーを保存してから、ユーザーに発行する必要があります。 これは、比較的複雑でわかりにくいコード構造につながる可能性があります。

私の人生を少し簡素化する方法はありますか？

OmniThreadLibrary （略してOTL）を紹介します。 OmniThreadLibraryは、Delphiでマルチスレッドアプリケーションを作成するためのライブラリです。 その作者であるスロベニアのPrimoz Gabrijelcicは、Delphiでの長年のアプリケーション開発経験を持つ卓越した専門家です。 OmniThreadLibraryは完全に無料のオープンソースライブラリです。 現時点では、ライブラリはすでにかなり成熟した段階にあり、深刻なプロジェクトでの使用に非常に適しています。



OTL情報はどこで入手できますか？

• このフォーラムで。
• ライブラリの作成者のブログ 。
• GoogleCode のプロジェクトページ 。

また、ライブラリの作成者は現在、OmniThreadLibraryとマルチスレッドに関するwiki-bookを埋めています。ほとんどの高レベルOTLプリミティブに関する記事が用意されています。

OTLが提供する機能は何ですか？

このライブラリには、WinAPIレベルでスレッドを作成/解放/同期するプロセスの詳細に進むことなく、マルチスレッドの管理を簡素化できる低レベルおよび高レベルのクラスが含まれています。

特に興味深いのは、マルチスレッド管理を簡素化するための高レベルのプリミティブです。 それらは、ソースコードの構造を実質的に変更することなく、既製のシングルスレッドアプリケーションに比較的簡単に統合できるという点で注目に値します。 これらのプリミティブにより、マルチスレッドを管理するための補助コードではなく、有用なアプリケーションコードに焦点を当てたマルチスレッドアプリケーションを作成できます。

主な高レベルプリミティブには、 Future （非同期関数）、 Pipeline （パイプライン）、 Join （いくつかのメソッドの並列呼び出し）、 ForkJoin （並列処理を伴う再帰）、 Async （非同期メソッド）、 ForEach （並列ループ）が含まれます。

私の意見では、最も興味深く有用なプリミティブはFutureとPipelineです。 それらを使用するために、既存のコードをほとんど書き換える必要はありません。

未来

このプリミティブを使用すると、非同期関数呼び出しを行い、適切なタイミングで計算が完了するのを待って実行結果を取得できます。 このプリミティブを使用すると、任意のプロシージャまたは関数の呼び出しを簡単に非同期に変換できます。

次のようになります。

uses OtlParallel; ... procedure TestFuture; var vFuture: IOmniFuture<integer>; begin //      vFuture := Parallel.Future<integer>( function: integer var i: integer; begin Result := 0; for i := 1 to 100000 do Result := Result + i; end ); //   -     (      (    ,    ,        ) //     ,     ShowMessage(IntToStr(vFuture.Value)); end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メインストリームと追加ストリームの同期の瞬間であるvFuture.Valueの呼び出しであることに注意してください。 Valueに戻るまで、別のスレッドの状態については何も知りません。 Valueを呼び出すとすぐに、追加のスレッドで計算が完了するまでメインスレッドが中断されます。



必要に応じて、メインスレッドで結果の非ブロッキング待機を実装できます。

 while not vFuture.IsDone do Application.ProcessMessages;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、Futureプリミティブを使用すると、非同期的にタスクを実行し、そこで必要なときに正確に結果をメインスレッドに返すことができます。

パイプライン

パイプライン（パイプライン）は、Futureと比べてはるかに強力なプリミティブです。

多くの要素に対して特定のアルゴリズムがループで実行されることを想像してください。 たとえば、ディレクトリ内のファイルの一部の処理が実行されます。 シングルスレッドのプログラムは、次のファイルを取得して読み取り、いくつかのアクションを実行し、変更されたファイルをディスクに保存します。 パイプラインを使用すると、初期アルゴリズムをステージ（読み取り、処理、保存）に分割し、これらのステージを並列スレッドで実行できます。 最初の段階では、最初のステージのみが開始され、最初のファイルを読み取ります。 読み取りが完了するとすぐに、2番目のステージが開始され、読み取りファイルまたはその部分の処理が開始されます（最初のステージがファイル全体ではなく部分的に読み取る場合）。 この時点で、最初のステージはすでに2番目のファイルの読み取りを開始しています。 2番目のステージが最初のファイルを処理するとすぐに、3番目のステージが接続して保存を開始します。 この時点で、3つのステージすべてが並行して動作する状態になります。

実際の生活に近いPipelineの例は、記事を読みすぎてしまうので、Pipelineの使用を説明するために、OtlBookからの絶対的な合成例のコピーに制限します（勝ち過ぎないでください！）。

 uses OtlCommon, OtlCollections, OtlParallel; var sum: integer; begin sum := Parallel.Pipeline .Stage( procedure (const input, output: IOmniBlockingCollection) var i: integer; begin for i := 1 to 1000000 do output.Add(i); end) .Stage( procedure (const input: TOmniValue; var output: TOmniValue) begin output := input.AsInteger * 3; end) .Stage( procedure (const input, output: IOmniBlockingCollection) var sum: integer; value: TOmniValue; begin sum := 0; for value in input do Inc(sum, value); output.Add(sum); end) .Run.Output.Next; end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、最初のステージで100万個の数値が生成され、それらが1つずつ次のステージに渡されます。 2番目の段階では、各数値に3を掛けて、3番目の段階に進みます。 3番目のステップは結果を要約し、単一の数値を返します。 各ステージは、独自のスレッドで実行されます。 さらに、Otlでは、単純な修飾子.NumTasks（N）により、各ステージで使用するスレッドの数（十分でない場合）を指定できます。 OTLの機能は非常に幅広いものです。



パイプラインステージ間のデータ交換をサポートするための基本クラスは、スレッドセーフキュークラス-TOmniBlockingCollectionです。 このクラスにより、複数のスレッドが同時にアイテムを追加および読み取ることができます。 コレクションの高速化は、トリッキーなメモリ管理と、OS同期オブジェクトに基づくロックではなく、スレッドセーフプロセッサ命令に基づくロックの使用により実現されます。 TOmniBlockingCollectionクラスの実装の詳細については、 こちら 、 こちら 、 こちらをご覧ください 。

おわりに

上記の例を見ている人は、「はい、私はすでにこれを見ました」と言うでしょう。 実際、.Net Framework 4のタスクパラレルライブラリには、ほぼ同じクラスが含まれています。 .Netマシン内でのスレッドの実行方法と、実際のプロセッサでのスレッドの実行方法には多くの違いがあります。 これらの違いを考慮することは、この記事の範囲外です。 すばらしいライブラリと、それがDelphi開発者に提供する幅広い可能性に注目したかっただけです。 ライブラリには、低レベルクラスと高レベルクラスの両方の使用を示す多数の例が含まれていることに注意してください。



このライブラリの成熟度と信頼性に対する不安を払拭するために、私は、（Webではなく）複雑な商用マルチユーザーアプリケーションでPipelineを使用することで、個別のストリームでのファイル処理により、クライアント上のファイルグループに対する操作の実行時間をほぼ半分に短縮できたと言えますクライアントとサーバーへの転送。 プロジェクトでDelphi + OmniThreadLibraryバンドルを使用するかどうかはあなた次第です;）