1

スレッド間でアクセスされるオブジェクト (一種のキュー) があります。いずれかのスレッドで使用される前に、キュー オブジェクトをミューテックス ロックすることができます。

これを管理するより簡単な方法は、ロックをキュー オブジェクト自体の内部に持ち込むことです。したがって、すべての API はキューをロックし、作業が完了すると解放します。このように、スレッドは各キューとともに追加のミューテックス変数を管理する必要がありません。

私の質問は、キューにアクセスしているスレッドが1つしかない場合があることです（ローカル変数であるとします）。しかし、本質的に、キューは最初に内部データ構造をロックし、終了する前にロックを解除するため、これはコストのかかる作業になるのでしょうか?

スレッド同期が特に必要ない場合、冗長なmutex_lockおよびmutex_unlock操作はどのくらいコストがかかりますか?

PS: 私の質問はこれに少し関連しています:ロックされていないミューテックスをロックするのはどのくらい効率的ですか? ミューテックスのコストはいくらですか?

しかし、私は自分のデザインとその理由の理解において特定の答えを探しています。

私は C と pthread ライブラリを使用しています。

4

2 に答える 2

1

これを処理する 1 つの方法は、キュー操作中にロックを取得する必要があるかどうかを示すパラメーターをキューの初期化に持たせることです。キューが単一のスレッドによって使用されている場合、ロックを取得/解放しないように初期化されます (または、取得/解放操作が nop であるロック オブジェクトを使用します)。

boost::pool がこれらの行に沿って何かを行う方法の例については、この回答を参照してください (ただし、C++ およびコンパイル時の構成として): https://stackoverflow.com/a/10188784/12711

同様の概念は、実行時に C コードにも適用できます。

于 2012-09-01T06:37:13.173 に答える
0

まず第一に、C ライブラリも pthreads もミューテックス ロックを実装していません。カーネルを呼び出して、そのために OS プリミティブを使用します。これは、mutes のパフォーマンスがベース OS によって大きく異なることを意味します。

アトミックな比較交換またはアトミックな増加と読み取り (このミレニアムの x86 など) をサポートするハードウェアへの移植性スペクトルを減らすことができる場合は、アトミックな増加と読み取りを使用して、ロックを必要としないスレッドセーフなキューを作成できます。

.Net プラットフォームの場合、http: //sourceforge.net/projects/dotnetlockless にそのような獣がいます。これを C に移植するのは非常に簡単なはずです。

于 2012-08-31T17:27:57.810 に答える