インテル®スレッディングビルディングブロックのタスクのグラフ、投機的ロック、アリーナの計算（続き）

この投稿は、Parallel Universe Magazine、Issue 18、2014 の記事 「フローグラフ、投機的ロック、およびインテルスレッディングビルディングブロックのタスクアリーナ」の翻訳の続きです 。トランザクション同期拡張機能とユーザー管理タスクアリーナ。これらは、並列処理のレベルとタスクの分離の高度な制御と管理を提供します。 興味があれば、猫にようこそ。

投機的ロック

Intel TBB 4.2は投機的ロックを提供します：Intel Transactional Synchronization Extensions（Intel TSX）テクノロジーに基づく新しい同期クラス。

投機的ロックを使用すると、アクセスとデータの変更が互いに競合しないことを前提に、このロックで保護されているクリティカルセクションを同時に実行できます。 実際には、データに競合がある場合、1つまたは複数の投機的実行を、保護されたデータに触れることなく、したがって他のストリームに影響を与えることなくキャンセルする必要があります。 その後、データの競合に関与するスレッドはクリティカルセクションを繰り返し、データを保護するために実際のロックを取得できます（Intel TSXテクノロジーは投機的実行が最終的に成功することを保証しません）。

インテルTBBライブラリーの投機的ロックの実装[6、7]では、これらのすべてのステップはユーザーに気付かれずに行われ、プログラマーは特別なミューテックスのAPIを使用するだけです。 さらに、Intel TSXテクノロジーをサポートしていないプロセッサーでは、実装はすぐに通常のロックを使用します。 つまり 開発者は、トランザクション同期を活用できる移植可能なプログラムを作成できます。

インテルTBBは、インテルTSXテクノロジーをサポートする2つのmutexクラスを提供しています： speculative_spin_mutexおよびspeculative_spin_rw_mutex ; 後者は、Intel TBB 4.2 Update 2の「プレビュー機能」として追加されました。

speculative_spin_mutexクラスは、 spin_mutexクラスに非常に似ています。 両方とも同じtbb / spin_mutex.hヘッダーファイルにあります。 もちろん、インテルTSXサポートを除いて、 speculative_spin_mutexの主な違いはサイズです。 キャッシュが他のデータと共有されないようにするため、競合やパフォーマンスの低下につながる可能性が非常に高いため、 speculative_spin_mutexオブジェクトインスタンスは2キャッシュラインを占有します。

投機的ロックの使用例：

#include <tbb/spin_mutex.h> #include <set> tbb::speculative_spin_mutex tsx_mtx; std::set<int> g_Set; void thread_safe_add_to_set( int value ) { tbb::speculative_spin_mutex::scoped_lock lock(tsx_mtx); g_Set.insert(value); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

speculative_spin_rw_mutexクラスは、その名前から推測できるように、投機的なRWスピンロックを実装しています。 投機的ロックは定義上排他的ではなく、同時に読み取ることができるだけでなく、競合がない場合は書き込むこともできます。 つまり、「投機的なRWロック」はトートロジーのように聞こえるかもしれません。 ただし、フローが「実際に」城をキャプチャできることを思い出してください。 この場合、 speculative_spin_mutexは、ストリームが何を行うかに関係なく、ストリームへの排他的アクセスを提供する必要があります—データの読み取りまたは変更。 したがって、これは真のRWロックではありません。 一方、 Speculative_spin_mutexは 、多くのデータリーダーの実行を許可します。 さらに、「本物の」リーダーと投機的なリーダーを同時に実行できます。 ただし、これには追加のオーバーヘッドが含まれます。複数のコアからキャッシュラインへの同時アクセスを回避するために、クラスの内部データフィールドを異なるキャッシュラインに格納する必要があります（偽共有）。 このため、 speculative_spin_rw_mutexクラスの各インスタンスは3つのキャッシュラインを占有します。

speculative_spin_rw_mutexは現在tbb / spin_rw_mutex.hヘッダーファイルにあり、実装の一部としてspin_rw_mutexを使用していますが、2つのクラスは完全に互換性がありません。 speculative_spin_rw_mutexクラスには 、 lock（）およびunlock（）メソッドがありません。 スコープテンプレートの使用を強制します。つまり、クラスspeculative_spin_rw_mutex :: scoped_lockからアクセスできる必要があります。 これはプレビューフィーチャクラスであるため、このヘッダーファイルをアタッチする前に、マクロTBB_PREVIEW_SPECULATIVE_SPIN_RW_MUTEXをゼロ以外の値に設定する必要があります。

残念ながら、投機的ロックの使用と利点はタスクに大きく依存しています。 これらの新しいクラスは「改善されたロック」だとは思わないでください。 投機的ロックが適切なツールであるとケースバイケースで判断するには、慎重なパフォーマンス調査が必要です。

ユーザー管理タスクアリーナ

ライブラリに最近追加された新しい機能のもう1つの重要な部分は、管理タスクアリーナです。 私たちの用語では、アリーナは、タスクを共有し、実行するタスクをピックアップするストリームの場所です。 当初、ライブラリはアプリケーションの1つのグローバルアリーナをサポートしていました。 次に、それを変更し、異なるスレッドによって起動された作業を相互に分離する必要があるというユーザーフィードバックに基づいて、アプリケーションスレッドごとに異なるアリーナをサポートできるようにしました。 その後、同時実行制御とジョブ分離がアプリケーションスレッドに関連しないようにリクエストを受け取りました。 これらのニーズを満たすために、タスク用のユーザー管理のアリーナを導入しました。 現時点では、これはまだプレビューフィーチャクラスであり、使用するにはマクロTBB_PREVIEW_TASK_ARENAをゼロ以外の値に設定する必要があります。 しかし、私たちは年内（2014年）に完全にサポートされるように取り組んでいます。

タスクのユーザー管理アリーナのAPIは、 task_arenaクラスを介して実装されます。 task_arenaクラスを定義するとき、ユーザーは目的の並列性と、アプリケーションスレッド用にどの程度の並列性を確保するかを指定できます。

 #define TBB_PREVIEW_TASK_ARENA 1 #include <tbb/task_arena.h> tbb::task_arena my_arena(4, 1);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、4つのスレッド用にアリーナが作成され、アプリケーションスレッド用に1つの場所が予約されています。 これは、Intel TBBライブラリによって管理される最大3つのワークフローがこの分野に参加し、この分野にあるタスクに取り組むことができることを意味します。 この領域に作業を追加できるアプリケーションスレッドの数に制限はありませんが、一般的な同時実行性は4に制限されます。 すべての「余分な」スレッドは、アリーナに参加してそこでタスクを実行することはできません。

アリーナに作業を送信するには、 execute（）またはenqueue（）メソッドを呼び出す必要があります。

 my_arena.enqueue( a_job_functor ); my_arena.execute( a_job_functor2 );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのメソッドの作業は、C ++ 11またはファンクターからのラムダ式で表すことができます。 これら2つの方法は、アリーナに作品を送信する方法によって区別されます。 task_arena :: enqueue（） -これは、「fire-and-forget」（send-and-forget）のような作業を送信するための非同期呼び出しです。 task_arena :: enqueue（）を呼び出したスレッドはアリーナに参加せず、この呼び出しからすぐに戻ります。 これに対して、 task_arena :: execute（）は、送信されたジョブが完了するまで戻りません。 可能であれば、 task_arena :: execute（）を呼び出したスレッドがアリーナに参加し、タスクを実行します。 そうでない場合、タスクが完了するまでスレッドはしばらくブロックされます。

多くのシーケンシャルタスクをtask_arenaに送信できますが、それは意図したものではありません。 通常、 タスクはtask_arenaに送信され、十分な並列処理が作成されます。たとえば、 parallel_forを呼び出します 。

 my_arena.execute( [&]{ tbb::parallel_for(0,N,iteration_functor()); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

またはフローグラフ：

 tbb::flow::graph g; ... // create the graph here my_arena.enqueue( [&]{ ... // start graph computations }); ... // do something else my_arena.execute( [&]{ g.wait_for_all(); }); // does not return until the flow graph finishes
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タスクアリーナの詳細については、Intel TBBリファレンスガイドを参照してください。

おわりに

Intel Threading Building BlocksテンプレートライブラリC ++は、効率的な高レベルのタスクベースの並列処理と、将来マルチコアアーキテクチャのフルパワーを使用できるポータブルアプリケーション開発を使用するための豊富なコンポーネントセットを提供します。 このライブラリにより、アプリケーション開発者は、この並列処理を管理するための低レベルの詳細に集中することなく、アプリケーション内のアルゴリズムの並列処理に集中できます。 このライブラリは、最も使用されている高レベルの並列アルゴリズムとスレッドセーフコンテナの高性能実装に加えて、スレッドセーフでスケーラブルなメモリマネージャー、ロック、アトミック操作などの低レベルビルディングブロックを提供します。

インテルTBBライブラリーはすでに非常に包括的であり、コミュニティーによって認識されているという事実にもかかわらず、私たちはそのパフォーマンスを改善し、機能を拡張し続けています。 Intel TBB 4.0では、開発者がデータまたは実行依存グラフに基づくアルゴリズムをより簡単に実装できるようにするために、計算グラフのサポートをリリースしました。 Intel TBB 4.2では、新しい同期クラスでIntel Transactional Synchronization Extensionsの利点をサポートし、ユーザーが管理するアリーナをタスクに導入することにより、並行性とタスクの分離の高度な制御と管理に対するユーザーリクエストに対応しました。

インテルTBBの最新バージョンと詳細情報については、次のサイトをご覧ください。

• 公式サイトsoftware.intel.com/en-us/intel-tbb
• オープンソースバージョンthreadingbuildingblocks.org
• ドキュメントソフトウェア .intel.com / en-us / tbb_4.2_ug
• フォーラムsoftware.intel.com/en-us/forums/intel-threading-building-blocks