問題タブ [lockless]

http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdfで説明されているハザードポインター手法を使用してロックレスキューを実装しました。実装にはGCCCAS命令を使用し、スレッドローカルにはpthreadローカルストレージを使用しました。構造。私は今、自分が書いたコードのパフォーマンスを評価しようとしています。特に、この実装と、キューを保護するためにロック（pthreadミューテックス）を使用する実装とを比較しようとしています。
ここでこの質問をしているのは、「ロックされた」キューと比較してみたところ、ロックレスの実装よりもパフォーマンスが優れていることがわかったためです。私が試した唯一のテストは、キューで10.000.000のランダム操作を実行する4コアx86_64マシンで4スレッドを作成することであり、ロックレスバージョンよりも大幅に高速です。

従うべきアプローチ、つまり、キューでテストする必要のある操作の種類と、ロックレスコードが時間を浪費している場所を確認するために使用できるツールの種類を提案できるかどうかを知りたいです。

また、4つのスレッドでは大幅な改善が見られないという理由だけで、ロックレスキューのパフォーマンスが低下する可能性があるかどうかも理解したいと思います...

ありがとう

これは、「単純に明白ですが、おそらく間違っている」カテゴリに分類されるように思われる質問の1つです。確かに、私はすべてのコーナーケースで機能する解決策を見つけるのに苦労しています。これは常に遭遇する問題のようです。

「ハードウェア」スレッドと「処理」スレッドがあります。

ハードウェアスレッドは、私がアクセスできない閉じたバイナリライブラリで実行されます。

処理スレッドは、ハードウェアの状態変化に関連する特定の（まれな）イベントを通知するために、ハードウェアスレッドにコールバックを登録します。

状態が変化したことを処理スレッドのイベントループに通知できるようにしたいと思います。外部ライブラリに依存したり、移植性のない方法で、ロックを使用せずにこれを実行したいと思います（ハードウェアスレッドがいつ処理スレッドに再度通知するかわからないため）。

それで、これをどのように解決するかについての現在の私の考えは次のようなものです：

明らかに、これがupdateラップアラウンドし、次に呼び出されるlocal_update前の値にたまたま到達した場合、これは壊れますprocessing_function（ただし、ほぼ確実に、これは決して発生しないと想定できます）。

ここで微妙な（またはそれほど微妙ではない）何かを見逃したことがありますか？

この問題全体を解決するためのより良い方法はありますか？

コールバックは、1つのスレッド（ハードウェアスレッド）からのみ呼び出されると想定できます。

私はかなりの C++ スキルを持っていますが、この 1 つのキャストで問題が発生しています。次のパラメータを受け取る関数があります: (volatile void **, void * , void*). 3 つint*の変数があり、それらを として渡そうとしてい(&var1, var2, var3)ます。ただし、次のエラーが表示されます: Cannot convert parameter 1 from int** to volatile void**. これを可能にするために作成する必要がある特定のキャストはありますか? 以下は、私が使用しているコードのスニペットです。どんな助けでも大歓迎です。

これは、Windows XP マシンの VS2010 で行われています。

少し変更して解決するプロデューサーの消費者の問題があります-多くの並列プロデューサーがありますが、1つの並列スレッドには1つの消費者しかありません。プロデューサーがバッファーに場所がない場合、要素を無視するだけです (コンシューマーを待たずに)。私はいくつかの C 疑似コードを書きました:

私は、このコードが正しいと 100% 確信しているわけではありません。発生する可能性のある問題を確認できますか? それとも、このコードをより良い方法で書くことができますか?

新しく改良されたロガーコンポーネント（.NET 3.5、C＃）を設計しています。

ロックフリーの実装を使用したいと思います。

ロギングイベントは（潜在的に）複数のスレッドから送信されますが、ファイル/他のストレージメディアへの実際の出力は単一のスレッドのみが行います。

本質的に、すべてのライターは、他のプロセス（LogFileWriter）によって取得されるように、データをキューに*キューイング*しています。

これはロックなしの方法で達成できますか？ネット上でこの特定の問題への直接の参照を見つけることができませんでした。

次の点を考慮してください。

*target をローカル変数に読み込み、ローカル変数が単に *target になるように最適化されないようにする方法が必要です。揮発性は答えですか？

私は Clojure クエスト (4clojure.com で約 80 の問題が解決されています) を進めており、読み続け、コーディングし、「理解」しようとしています。

Clojure が「ロックレス同時実行」用に設計されていることに少し混乱しています。私はデッドロックについてよく知っています ( 「I'm in Expert in concurrency」ではなく、「デッドロックに終わった貧弱な Java コードを書いた」のように)。私もこれを読みました：

なぜ (Clojure で) ロックレスな同時実行がそれほど重要なのでしょうか?

Clojure プログラムがデッドロックにならないということの素晴らしさを実感しています。

しかし、私は少し混乱しています: そのような偉業は内部でロックフリーアルゴリズムを実装することによって達成されるのでしょうか、それとも「デッドロック可能な」アルゴリズムが使用される可能性がありますが、デッドロックしないことが保証された正しい実装を使用することでしょうか (Clojure プログラマーにはどういうわけか「隠されている」でしょう)。 )?

ロックフリー アルゴリズムに関するハッカー ニュースに関する最近の議論があります。

http://news.ycombinator.com/item?id=4103921

1024cores.netの次の「ロックフリー アルゴリズム」ページを参照します。

http://www.1024cores.net/home/lock-free-algorithms

この記事と Clojure での同時実行の仕組みとの関係がわかりません。

Clojure で並行プログラムを開発しているとき、「ロックとロックフリーのアルゴリズム」は私にとって問題ではないということですか?

ロックレス/ロックフリーのリンクリストについて、オンラインでさまざまなソリューションを検討してきました。この問題を解決するために、RCU、ハザードポインター、補助ノード/「マーキング」ノードに関する出版物などの手法に出くわしました。それらはすべて、複数のライターとリーダーの同時実行の問題を解決します。
これらのソリューションを追求する前に、単一のライターと複数のリーダーがリンクされたリストに対して、ロックフリーアルゴリズムを開発するためのより簡単で標準的な手法があるかどうかを確認したいと思いました。(サポートされている操作は、追加、削除、検索、および更新です)

御時間ありがとうございます。スリ

TCPストリームからのデータを消費する必要がある複数のスレッドがあります。TCPソケットから読み取るために、共有メモリ内の循環バッファ/キューを使用したいと思います。TCP受信は、循環キューに直接書き込みます。コンシューマーはキューから読み取ります。

この設計では、ゼロコピーとゼロロックを有効にする必要があります。ただし、ここには2つの異なる問題があります。

1. TCPソケットから1つの論理メッセージだけを読み取ることは可能/効率的ですか？そうでない場合で、複数のメッセージを読んだ場合は、残差をこれからthis->nextにコピーする必要があります。

2. ロックレスキューを実装することは本当に可能ですか？不可分操作があることは知っていますが、これらもコストがかかる可能性があります。すべてのCPUキャッシュを無効にする必要があるためです。これは、24コアすべてのすべての操作に影響します。

低レベルのTCPで少し錆びており、メッセージがいつ完了したかを正確に判断する方法がわかりません。\ 0を探しますか、それとも実装固有ですか？

ty

汎用フィールドとそれをカプセル化するプロパティがあります。

問題は、このプロパティが1つのスレッドから書き込まれ、同時に複数のスレッドから読み取られる可能性があることです。また、Tがstruct、またはの場合long、読者は一部が古い値で一部が新しい値の結果を取得する可能性があります。どうすればそれを防ぐことができますか？

を使用してみvolatileましたが、それは不可能です。

揮発性フィールドのタイプを「T」にすることはできません。

これは私がすでに書いたコードのより単純なケースであり、を使用ConcurrentQueue<T>しているので、ここでも使用することを考えました。

これはうまくいくでしょうが、それは単純なはずの何かに対する過度に複雑な解決策であるように私には思えます。

パフォーマンスは重要であるため、可能であれば、ロックは回避する必要があります。

setと同時に発生した場合、古い値を返すか新しい値を返すgetかは関係ありません。get