4

Disruptor は POD データ型にのみ使用する必要がありますか?

つまり、次のような値を取るDisruptor<T>ためだけに使用する必要があります。Tbyte[], int[], etc

私の疑いは、メンバー変数として参照Tを持つものを使用する場合、ヒープにあるそれらのメンバー変数が必要であるということです。メンバー変数がヒープの完全に別の部分にある可能性があるため、これもキャッシュミスにつながります。Objectnew

Plain Old Datatypes (POD) のセットに属するためDisruptor<T>だけに使用されるべきであるという私の考えは正しいですか?T

よろしく、 VImal

更新: 他の誰かがこの質問を見てもらえますか?

更新 2:

@トリシャに返信

こんにちはトリシャ、

ご挨拶。

あなたが言及したリンクを見ました。

com.lmax.ticketing.api.Messageから継承されjavolution.io.Struct、 から要素で構成され、javolution.io.Structとの間で相互運用可能になりjavolution.io.Unionます。メモリ レイアウト から継承するクラスは、のメンバーの初期化順序によって定義され、構造体と同じ wordSize 規則に従います。MessageC/C++javolution.io.Struct/UnionStruct/UnionC/C++

したがって、本質的には、 に配置する要素のメモリ レイアウトを制御できますDisruptor。また、 のすべてのメンバーとサブメンバーMessageは固定サイズです。つまり、動的メモリはありません ( java.lang.Object)

それはまさに私のポイントでもあり、メモリレイアウトを制御でき、動的メモリを持たない要素を使用する必要があるということです。これは、キャッシュミスを最小限に抑えるために行われます。

たとえば、メッセージの一部が であった場合、java.lang.StringJIT コンパイラーがその文字列をどこに配置したかはわかりません。にアクセスしてMessage.StringいるEventHandler場合、文字列がメモリのまったく異なるチャンクに存在する可能性があるため、キャッシュミスが発生する可能性があります..

私は正しいですか?

4

2 に答える 2

3

任意のタイプのオブジェクトをイベントとして使用できます。たとえば、https ://github.com/mikeb01/ticketing のコードを参照してください(例: com.lmax.ticketing.web.RequestServlet) - これはMessageRingBuffer.

には、コンストラクターを呼び出すときに指定された を使用して、これらのRingBufferイベントが事前に取り込まれます。したがって、 の作成時にそれらの新しいインスタンスを作成するだけで、 の存続期間中はそれらを再利用できます。繰り返しますが、上記のプロジェクトでこの例を見ることができます。EventFactoryDisruptorRingBufferDisruptor

于 2012-02-17T13:41:16.893 に答える
1

あなたが書いたコードには制限がないので、私はノーと言います。作者がそのようなことを意図した場合、コードはそれを強制する必要があります。

更新:あなたは答えを持っています:「いいえ」。さらに100の「いいえ」の回答が得られた場合でも、黒い白鳥が現れる場合に備えて待つ必要がありますか?これが問題であることを示すデータはありますか?

すべてのキャッシングソリューションが同じ運命をたどると思いますか?他のキャッシングソリューションにそのような制限がないことを私は知っています。それは検討する価値のあるより多くの証拠ですか?

于 2012-02-17T12:01:38.360 に答える