🏂🏼 🙊 🍔 マルチスレッドアプリケーションでのシングルトン実装 🤚🏻 🍘 👨🏿‍🏭

はじめに

現時点では、単一のスレッドで実行されるソフトウェアを想像することは困難です。もちろん、1つのスレッドで十分な数の単純なタスクがあります。ただし、これは常に当てはまることではなく、中または高複雑度のほとんどのタスクは何らかの方法でマルチスレッドを使用します。この記事では、マルチスレッド環境でのシングルトーンの使用について説明します。見かけの単純さにもかかわらず、このトピックには多くのニュアンスと興味深い質問が含まれているため、別の記事に値すると思います。シングルトーンを使用する理由と、それらを正しく使用する方法については触れません。これらの問題を明確にするために、シングルトンに関連するさまざまな問題に関する以前の記事を参照することをお勧めします[1] 、 [2] 、 [3] 。この記事では、シングルスレッドの実装に対するマルチスレッドの影響について説明し、開発中に発生する問題について説明します。

問題の声明

以前の記事では、次のシングルトン実装が検討されました。

template<typename T> T& single() { static T t; return t; }

この関数の考え方は非常にシンプルで簡単です：任意のタイプTについて、オンデマンドでこのタイプのインスタンスを作成できます。「遅延」、およびこの関数によって作成されるインスタンスの数は1を超えません。インスタンスが必要ない場合は、マルチスレッドに関して（およびライフタイムやその他の問題に関して）問題はありません。しかし、マルチスレッドアプリケーションで同時に2つ以上のスレッドが同じタイプTでこの関数を呼び出したい場合はどうなりますか？

C ++標準

実用的な観点からこの質問に答える前に、理論的な側面、すなわち、 C ++標準に精通します。現在、コンパイラは2003と2011の2つの標準をサポートしています。

6.7.4ドル、C ++ 03

静的ストレージ期間（3.7.1）を持つすべてのローカルオブジェクトのゼロ初期化（8.5）は、他の初期化が行われる前に実行されます。 constant-expressionsで初期化された静的ストレージ期間を持つPODタイプ（3.9）のローカルオブジェクトは、ブロックに入る前に初期化されます。実装は、ネームスペーススコープ（3.6.2）の静的ストレージ期間でオブジェクトを静的に初期化できるのと同じ条件下で、静的ストレージ期間で他のローカルオブジェクトの初期初期化を実行できます。それ以外の場合、そのようなオブジェクトは、コントロールがその宣言を初めて通過するときに初期化されます。そのようなオブジェクトは、初期化の完了時に初期化されたと見なされます。例外をスローして初期化が終了した場合、初期化は完了していないため、コントロールが次に宣言に入るときに再試行されます。オブジェクトの初期化中にコントロールが宣言を（再帰的に）再入力した場合、動作は未定義です。

6.7.4ドル、C ++ 11

静的ストレージ期間（3.7.1）またはスレッドストレージ期間（3.7.2）を持つすべてのブロックスコープ変数のゼロ初期化（8.5）は、他の初期化が行われる前に実行されます。該当する場合、静的ストレージ期間を持つブロックスコープエンティティの定数初期化（3.6.2）は、そのブロックが最初に入力される前に実行されます。実装は、ネームスペーススコープ（3.6.2）の静的またはスレッドストレージ期間で変数を静的に初期化できるのと同じ条件下で、静的またはスレッドストレージ期間で他のブロックスコープ変数の初期初期化を実行できます。そうでない場合、そのような変数は、コントロールがその宣言を最初に通過するときに初期化されます。このような変数は、初期化が完了すると初期化されたと見なされます。例外をスローして初期化が終了した場合、初期化は完了していないため、コントロールが次に宣言に入るときに再試行されます。 変数の初期化中に制御が同時に宣言に入ると、同時実行は初期化の完了を待機します（*） 。変数が初期化されている間に制御が宣言を再帰的に再入力する場合、動作は未定義です。

（*）実装は、イニシャライザの実行にデッドロックを導入してはなりません。

（ 私が強調表示 ）

要するに、新しい標準では、変数の初期化（つまり、インスタンスの作成）中に2番目のスレッドが同じ変数にアクセスしようとすると、実装（スレッド）は初期化が完了するのを待つべきですが、実装は許可すべきではありませんデッドロック状態。あなたが見ることができるように、以前のマルチスレッド標準では、言葉は言われていません。

どのコンパイラが新しい標準を実際にサポートし、どのコンパイラがサポートしているふりをしようとしているのかを調べることは今でも残っています。これを行うために、次の実験を実行します。

実験

マルチスレッドプリミティブを使用するときは、 Ultimate ++フレームワークを使用します。非常に軽量で使いやすいです。この記事のフレームワークでは、これは基本的な役割を果たしません（たとえば、 boostを使用できます）。

この実験では、作成にかなり時間がかかるクラスを作成します。

 struct A { A() { Cout() << '{'; //     Thread::Sleep(10); //  10  if (++ x != 1) Cout() << '2'; //  :    Cout() << '}'; //    } ~A() { Cout() << '~'; //   } int x; };

クラスを作成する最初の瞬間、xの値は0です。シングルトンからのみ使用する予定です。 staticという単語を使用すると、すべてのPODタイプは値0で初期化されます。その後、操作の継続時間をエミュレートして、しばらく待機します。最後に期待値のチェックがあり、それが単一性と異なる場合、エラーメッセージが表示されます。ここでは、操作のシーケンスをより明確に示すために、文字出力を使用しました。私は特にメッセージを使用しませんでしたこれには、マルチスレッドで使用するための追加の同期が必要になります。

次に、新しいスレッドを作成するときに呼び出される関数を作成します。

 void threadFunction(int i) { Cout() << char('a'+i); //   -    ,    A& a = single<A>(); //    if (ax == 0) Cout() << '0'; //  :    Cout() << char('A'+i); //   -    }

また、5つのスレッドからthreadFunction関数を同時に呼び出して、シングルトンへの競合アクセスがある場合の状況をエミュレートします。

 for (int i = 0; i < 5; ++ i) Thread::Start(callback1(threadFunction, i)); Thread::ShutdownThreads();

実験のために、今日非常に人気のある2つのコンパイラーMSVC 2010とGCC 4.5を選択しました。また、 MSVC 2012コンパイラを使用してテストを実施しました。結果は2010バージョンと完全に一致しているため、今後は言及しません。

GCCの起動結果：

ab {cde} ABCDE〜

MSVCの起動結果：

ab {0cB0dCe00DE} A〜

実験結果の議論

結果について説明します。 GCCの場合、次のことが発生します。

スレッド1のthreadFunctionを開始します
スレッド2のthreadFunctionを開始します
シングルトン初期化開始
スレッド3のthreadFunctionを開始します
スレッド4のthreadFunctionを開始します
スレッド5のthreadFunctionを開始します
シングルトン初期化完了
すべてのスレッド1〜5に対してthreadFunctionを順次終了
プログラムの終了とシングルトンの破壊

シングルトンは一度だけ初期化され、threadFunction関数は、シングルトンの初期化=> GCCがマルチスレッド環境でオブジェクトを正しく初期化した後にのみ作業を終了します。

MSVCの状況は多少異なります。

スレッド1のthreadFunctionを開始します
スレッド2のthreadFunctionを開始します
シングルトン初期化開始
エラー：シングルトンが初期化されていません
スレッド3のthreadFunctionを開始します
スレッド2のスレッド関数を終了します
エラー：シングルトンが初期化されていません
...
スレッド5のthreadFunctionを終了します
シングルトン初期化完了
スレッド1のスレッド関数を終了します
プログラムの終了とシングルトンの破壊

この場合、最初のストリームのコンパイラーはシングルトンの初期化を開始し、残りのコンパイラーは初期化する時間さえなかったオブジェクトを直ちに返します。したがって、 MSVCはマルチスレッド環境では正しく機能しません。

実験結果の分析

考慮されたコンパイラによって得られた結果がどのように異なるかを理解してみましょう。これを行うには、コードをコンパイルおよび逆アセンブルします。

GCC ：

 5 T& single() 0x00418ad8 <+0>: push %ebp 0x00418ad9 <+1>: mov %esp,%ebp 0x00418adb <+3>: sub $0x28,%esp 6 { 7 static T t; 0x00418ade <+6>: cmpb $0x0,0x48e070 0x00418ae5 <+13>: je 0x418af0 <single<A>()+24> 0x00418ae7 <+15>: mov $0x49b780,%eax 0x00418aec <+20>: leave 0x00418aed <+21>: ret 0x00418af0 <+24>: movl $0x48e070,(%esp) 0x00418af7 <+31>: call 0x485470 <__cxa_guard_acquire> 0x00418afc <+36>: test %eax,%eax 0x00418afe <+38>: je 0x418ae7 <single<A>()+15> 0x00418b00 <+40>: movl $0x49b780,(%esp) 0x00418b07 <+47>: call 0x4195d8 <A::A()> 0x00418b0c <+52>: movl $0x48e070,(%esp) 0x00418b13 <+59>: call 0x4855cc <__cxa_guard_release> 0x00418b18 <+64>: movl $0x485f04,(%esp) 0x00418b1f <+71>: call 0x401000 <atexit> 8 return t; 9 } 0x00418b24 <+76>: mov $0x49b780,%eax 0x00418b29 <+81>: leave 0x00418b2a <+82>: ret

オブジェクトAのコンストラクターを呼び出す前に、コンパイラーは同期関数__cxa_guard_acquire / __ cxa_guard_releaseの呼び出しを挿入することがわかります。これにより、シングルトンの初期化と同時に単一の関数を安全に実行できます。

MSVC ：

 T& single() { 00E51420 mov eax,dword ptr fs:[00000000h] 00E51426 push 0FFFFFFFFh 00E51428 push offset __ehhandler$??$single@UA@@@@YAAAUA@@XZ (0EE128Eh) 00E5142D push eax static T t; 00E5142E mov eax,1 00E51433 mov dword ptr fs:[0],esp ;   00E5143A test byte ptr [`single<A>'::`2'::`local static guard' (0F23944h)],al 00E51440 jne single<A>+47h (0E51467h) ;     "" 00E51442 or dword ptr [`single<A>'::`2'::`local static guard' (0F23944h)],eax 00E51448 mov ecx,offset t (0F23940h) 00E5144D mov dword ptr [esp+8],0 ;  :   00E51455 call A::A (0E51055h) 00E5145A push offset `single<A>'::`2'::`dynamic atexit destructor for 't'' (0EED390h) 00E5145F call atexit (0EA0AD1h) 00E51464 add esp,4 return t; } 00E51467 mov ecx,dword ptr [esp] 00E5146A mov eax,offset t (0F23940h) 00E5146F mov dword ptr fs:[0],ecx 00E51476 add esp,0Ch 00E51479 ret

ここでは、コンパイラは0x0F23944の変数を使用して初期化を検証します。オブジェクトがまだ初期化されていない場合、この値は1に設定され、シングルトンの初期化が無料で呼び出されます。実験の結果として得られた結果を説明する同期が提供されていないことがわかります。

シンプルなソリューション

私たちの問題を解決するかなり簡単なソリューションを使用できます。これを行うには、オブジェクトを作成する前に、mutexを使用してオブジェクトへのアクセスを同期します。

 //        struct StaticLock : Mutex::Lock { StaticLock() : Mutex::Lock(mutex) { Cout() << '+'; } ~StaticLock() { Cout() << '-'; } private: static Mutex mutex; }; Mutex StaticLock::mutex; template<typename T> T& single() { StaticLock lock; //   mutex.lock() static T t; //   return t; //  mutex.unlock()    }

起動結果：

ab + {cde} -A + -B + -C + -D + -E〜

操作のシーケンス：

スレッド1のthreadFunctionを開始します
スレッド2のthreadFunctionを開始します
グローバルロックの取得：mutex.lock（）
シングルトン初期化開始
スレッド3のthreadFunctionを開始します
スレッド4のthreadFunctionを開始します
スレッド5のthreadFunctionを開始します
シングルトン初期化完了
グローバルロックリリース：mutex.unlock（）
スレッド1のスレッド関数を終了します
グローバルロックの取得：mutex.lock（）
グローバルロックリリース：mutex.unlock（）
スレッド2のスレッド関数を終了します
...
スレッド5のthreadFunctionを終了します
プログラムの終了とシングルトンの破壊

このような実装は、初期化されていないオブジェクトを返す問題を完全に排除します。初期化の前にmutex.lock（）が呼び出され、初期化の完了後にmutex.unlock（）が呼び出されます。残りのスレッドは、初期化が完了するのを待ってから使用します。ただし、このアプローチには大きなマイナス点があります。オブジェクトが既に初期化されているかどうかに関係なく、常にロックが使用されます。パフォーマンスを改善するために、まだ初期化されていないオブジェクト（ GCCに実装されている）にアクセスしたいときにのみ同期を使用したいと思います。

ダブルチェックロックパターン

上記のアイデアを実装するために、ダブルチェックロックパターン（ DCLP ）またはダブルチェックロック設計パターンと呼ばれるアプローチがよく使用されます。その本質は、次の一連のアクションによって説明されます。

状態チェック：初期化されているかどうかはいの場合、すぐにオブジェクトへのリンクを返します
ロックを取ります
初期化された場合、もう一度条件を確認し、ロックを解除してリンクを返します
シングルトンを初期化する
条件を「初期化済み」に変更します
ロックを解除してリンクを返す

この一連のアクションから、名前の由来が明らかになります。条件を2回確認します。最初にブロックする前に、次にすぐに確認します。たとえば、2つのスレッドが同時にこの関数に入った場合、最初のチェックはオブジェクトが初期化されていないことを意味しない可能性があります。この場合、両方のスレッドが「初期化されていない」ステータスを受け取り、一方のスレッドがロックを取得し、もう一方が待機します。したがって、ロックで待機中のスレッドは、追加のチェックを行わない場合、シングルトンを再初期化し、悲しい結果を招く可能性があります。

DCLPは、次の例で説明できます。

 template<typename T> T& single() { static T* pt; if (pt == 0) //  ,   { StaticLock lock; if (pt == 0) //  ,   pt = new T; } return *pt; }

ここでは、作成された型へのポインターが条件として機能します。ゼロに等しい場合は、オブジェクトを初期化する必要があります。すべてが問題ないように見えます。パフォーマンスの問題はなく、すべてがうまく機能します。しかし、すべてがそれほどバラ色ではないことが判明しました。かつて、これはパターンではなく、アンチパターン、つまり使用すべきではありません微妙なエラーにつながります。問題が何であるかを把握してみましょう。

まず、このようなシングルトンは削除されませんが、これはそれほど大きな問題ではありません。シングルトンの有効期間はアプリケーションの稼働時間と一致するため、オペレーティングシステムはすべてをクリーンアップします（もちろん、メッセージログまたは特定のリクエストをデータベースに送信して、アプリケーションステータスレコードを変更します）。

2番目に深刻な問題は、次の行です。

 pt = new T;

これをさらに詳しく考えてみましょう。この行は次のように書き換えることができます（簡潔にするため、例外処理は省略します）。

 pt = operator new(sizeof(T)); //     new (pt) T; // placement new:

つまりメモリが最初に割り当てられ、次にコンストラクターを呼び出してオブジェクトが初期化されます。そのため、メモリが既に割り当てられており、pt値が更新されており、オブジェクトがまだ作成されていないことが判明する場合があります。したがって、スレッドがロック外で最初のチェックを実行する場合、単一の関数は割り当てられたが初期化されていないメモリへの参照を返します。

ここで、上記の両方の問題を修正してみましょう。

提案されたアプローチ

シングルトンを作成するための2つの関数を紹介します。1つはシングルスレッドアプリケーションがあるように使用し、もう1つはマルチスレッド用に使用します。

 //      template<typename T> T& singleUnsafe() { static T t; return t; } //       template<typename T> T& single() { static T* volatile pt; if (pt == 0) { T* tmp; { StaticLock lock; tmp = &singleUnsafe<T>(); } pt = tmp; } return *pt; }

その考え方は次のとおりです。最初の実装（現在はsingleUnsafe関数）は、シングルスレッドアプリケーションで正常に動作することを知っています。したがって、必要なのは、ロックの正しい使用によって達成される呼び出しのシリアル化だけです。ある意味では、2つのチェックもあります。ロックの外側の最初のチェックのみがポインターを使用し、2番目のチェックはコンパイラーによって生成された内部変数を使用します。また、volatileキーワードを使用して、コンパイラーによる最適化が過剰に行われた場合の操作の順序変更を防ぎます。また、ptポインターの割り当てがロック外で発生することにも注意してください。これは、コード実行中にプロセッサによる操作の並べ替えを防ぐためです。

そのような実装をコンパイルした結果を以下に示します。

 template<typename T> T& single() { ;   00083B30 push 0FFFFFFFFh 00083B32 push offset __ehhandler$??$single@UA@@@@YAAAUA@@XZ (0A13B6h) 00083B37 mov eax,dword ptr fs:[00000000h] 00083B3D push eax 00083B3E mov dword ptr fs:[0],esp 00083B45 push ecx static T* volatile pt; if (pt == 0) ;     00083B46 mov eax,dword ptr [pt (0E3950h)] 00083B4B test eax,eax 00083B4D jne single<A>+7Dh (83BADh) { T* tmp; { StaticLock lock; ;   EnterCriticalSection    00083B4F push offset staticMutex (0E3954h) 00083B54 mov dword ptr [esp+4],offset staticMutex (0E3954h) 00083B5C call dword ptr [__imp__EnterCriticalSection@4 (0ED6A4h)] tmp = &singleUnsafe<T>(); 00083B62 mov eax,1 00083B67 mov dword ptr [esp+0Ch],0 ;   00083B6F test byte ptr [`singleUnsafe<A>'::`2'::`local static guard' (0E394Ch)],al 00083B75 jne single<A>+68h (83B98h) 00083B77 or dword ptr [`singleUnsafe<A>'::`2'::`local static guard' (0E394Ch)],eax 00083B7D mov ecx,offset t (0E3948h) 00083B82 mov byte ptr [esp+0Ch],al ;  :   00083B86 call A::A (1105Fh) 00083B8B push offset `singleUnsafe<A>'::`2'::`dynamic atexit destructor for 't'' (0AD4D0h) 00083B90 call atexit (60BB1h) 00083B95 add esp,4 } ;   LeaveCriticalSection    00083B98 push offset staticMutex (0E3954h) 00083B9D call dword ptr [__imp__LeaveCriticalSection@4 (0ED6ACh)] pt = tmp; ;    pt    00083BA3 mov dword ptr [pt (0E3950h)],offset t (0E3948h) } return *pt; } 00083BAD mov ecx,dword ptr [esp+4] ;     eax 00083BB1 mov eax,dword ptr [pt (0E3950h)] 00083BB6 mov dword ptr fs:[0],ecx 00083BBD add esp,10h 00083BC0 ret

アセンブラーコードにコメントを追加して、何が起こっているのかを明確にしました。例外処理コードに注目するのは興味深いです：非常に印象的な作品です。 GCCコードと比較できます。GCCコードでは、生成された例外がない場合、オーバーヘッドなしでスタックの昇格にテーブルが使用されます。 MSVCコンパイラのx64プラットフォームのコードを見ると、例外処理へのわずかに異なるアプローチを見ることができます。

 template<typename T> T& single() { 000000013F401600 push rdi 000000013F401602 sub rsp,30h 000000013F401606 mov qword ptr [rsp+20h],0FFFFFFFFFFFFFFFEh 000000013F40160F mov qword ptr [rsp+48h],rbx static T* volatile pt; if (pt == 0) 000000013F401614 mov rax,qword ptr [pt (13F4F5890h)] 000000013F40161B test rax,rax 000000013F40161E jne single<A>+75h (13F401675h) { T* tmp; { StaticLock lock; 000000013F401620 lea rbx,[staticMutex (13F4F58A0h)] 000000013F401627 mov qword ptr [lock],rbx 000000013F40162C mov rcx,rbx 000000013F40162F call qword ptr [__imp_EnterCriticalSection (13F50CCC0h)] ; nop !!! 000000013F401635 nop tmp = &singleUnsafe<T>(); 000000013F401636 mov eax,dword ptr [`singleUnsafe<A>'::`2'::`local static guard' (13F4F588Ch)] 000000013F40163C lea rdi,[t (13F4F5888h)] 000000013F401643 test al,1 000000013F401645 jne single<A>+65h (13F401665h) 000000013F401647 or eax,1 000000013F40164A mov dword ptr [`singleUnsafe<A>'::`2'::`local static guard' (13F4F588Ch)],eax 000000013F401650 mov rcx,rdi 000000013F401653 call A::A (13F401087h) 000000013F401658 lea rcx,[`singleUnsafe<A>'::`2'::`dynamic atexit destructor for 't'' (13F4A6FF0h)] 000000013F40165F call atexit (13F456664h) ; nop !!! 000000013F401664 nop } 000000013F401665 mov rcx,rbx 000000013F401668 call qword ptr [__imp_LeaveCriticalSection (13F50CCD0h)] pt = tmp; 000000013F40166E mov qword ptr [pt (13F4F5890h)],rdi } return *pt; 000000013F401675 mov rax,qword ptr [pt (13F4F5890h)] } 000000013F40167C mov rbx,qword ptr [rsp+48h] 000000013F401681 add rsp,30h 000000013F401685 pop rdi 000000013F401686 ret

特にnopの指示に注意しました。これらは、例外が生成された場合のスタックプロモーションのマーカーとして使用されます。このアプローチには、生成された例外がない場合のコード実行のオーバーヘッドもありません。

結論

それで、結論を出す時です。この記事は、コンパイラーごとに新しい標準に対する態度が異なることを示しています。GCCは、最新の現実に適応するよう最善を尽くし、マルチスレッド環境でシングルトーンの初期化を正しく処理します。 MSVCは少し遅れているため、この記事で説明されているきちんとしたシングルトン実装が必要です。上記のアプローチは、深刻な同期オーバーヘッドのない普遍的で効率的な実装です。

PS

この記事は、マルチスレッドの問題の概要です。シングルトンオブジェクトを作成するときのアクセスの問題を解決します。彼のデータをさらに使用すると、他の重大な問題が発生します。これについては、次の記事で詳しく説明します。

更新する

シングルトンの実装は、記事へのコメントを考慮して修正されました。

文学

[1] Habrahabr：シングルトンパターンの使用

[2] Habrahabr：シングルトンとオブジェクトの寿命

[3] Habrahabr：依存関係の反転と設計パターンの生成

[4] Final Committee Draft (FCD) of the C++0x standard

[5] C++ Standard — ANSI ISO IEC 14882 2003

[6] Ultimate++: C++ cross-platform rapid application development framework

[7] Boost C++ libraries

[8] Wikipedia: Double-checked locking

[9] , double-checked locking

マルチスレッドアプリケーションでのシングルトン実装