multithreading - gccでのスレッドセーフなアトミック操作

Question

私が取り組んでいるプログラムには、次のようなコードがたくさんあります。

pthread_mutex_lock( &frame->mutex );
frame->variable = variable;
pthread_mutex_unlock( &frame->mutex );

真ん中の命令をアトミックストアに置き換えることができれば、これは明らかにCPUサイクルの無駄です。gccがこれを実行できることは知っていますが、このような単純なスレッドセーフなアトミック操作に関するドキュメントはあまり見つかりませんでした。このコードセットをアトミック操作に置き換えるにはどうすればよいですか？

（単純なストアは理論的にはアトミックである必要があることはわかっていますが、オプティマイザーがプロセスのある時点でアトミック性を台無しにしないことを期待する必要はありません。）

明確化：厳密にアトミックである必要はありません。これらの変数は、スレッドの同期にのみ使用されます。つまり、スレッドBは値を読み取り、その値が正しいかどうかを確認し、正しくない場合はスリープします。したがって、スレッドAが値を更新し、スレッドBがその更新を認識しない場合でも、問題はありません。これは、スレッドBが実際には必要のないときにスリープし、ウェイクアップすると値がスリープすることを意味するためです。正しいこと。

Answer 1

gccのドキュメントを確認できます。現在のgccバージョン（4.3.2）の場合は、5.47章になります。アトミックメモリアクセス用の組み込み関数-他のgccバージョンの場合は、ドキュメントを確認してください。それは第5章-C言語ファミリーの拡張にあるはずです。

ちなみに、Cコンパイラは、単純なストア操作がアトミックであることをまったく保証しません。その仮定に頼ることはできません。マシンのオペコードをアトミ​​ックに実行するには、LOCKプレフィックスが必要です。

Answer 2

ある時点まで、C のアトミック操作は、atomic.h ヘッダーを介してカーネル ソースから直接提供されていました。

ただし、カーネル ヘッダーをユーザー空間コードで直接使用することは非常に悪い習慣であるため、atomic.h ヘッダー ファイルは少し前に削除されました。代わりに、はるかに優れた信頼性の高いアプローチである「GCC Atomic Builtins」を利用できるようになりました。

Tudor Golubenco が彼のブログで提供している非常に良い説明があります。彼は、必要なコードがある場合に備えて、初期の atom.h ファイルのドロップイン置換も提供しています。

残念ながら、私はスタックオーバーフローを初めて使用するので、コメントで使用できるリンクは 1 つだけです。Tudor の投稿を確認して、知識を得てください。

Answer 3

x86 およびその他のほとんどのアーキテクチャでは、整列された 4 バイトの読み取りと書き込みは常にアトミックです。ただし、オプティマイザーは、単一のスレッド内で読み取りと書き込みをスキップ/再順序付けする場合があります。

あなたがしたいことは、他のスレッドがこのメモリ位置に触れた可能性があることをコンパイラに通知することです。( の副作用はpthread_mutex_lock、他のスレッドがメモリの一部に触れた可能性があることをコンパイラに伝えることです。)volatile推奨されているように見えるかもしれませんが、これは C 仕様ではなく、GCC はそのように解釈しませんvolatile。

asm("" : "=m" (variable));
frame->variable = variable;

variableは、「書き込み済みです。リロードしてください」と言う GCC 固有のメカニズムです。

Answer 4

私の知る限り、MOV命令の前にLOCKを付けることはできません。これは、RMW 操作でのみ許可されます。ただし、単純なストアを使用する場合は、ロックを許可する命令だけでなく、mutex で暗黙的に使用されるメモリ バリアも必要になる可能性があります。

Answer 5

ご覧のとおり、開発に gnu プラットフォームを使用しているため、glic はアトミック機能の範囲のデータ型 int を提供すると言っても過言ではありません'sig_atomic_t'。したがって、このアプローチにより、カーネル レベルでのアトミック操作を保証できます。gcc レベルではありません。