why padding on sequence?

[Terry Tan]

hi all,

I have read the source of sequence , like below 

public class Sequence

{

    private static final AtomicLongFieldUpdater<Sequence> updater = AtomicLongFieldUpdater.newUpdater(Sequence.class, "value");

    private volatile long p1 = 7L, p2 = 7L, p3 = 7L, p4 = 7L, p5 = 7L, p6 = 7L, p7 = 7L,

                          value = Sequencer.INITIAL_CURSOR_VALUE,

                          q1 = 7L, q2 = 7L, q3 = 7L, q4 = 7L, q5 = 7L, q6 = 7L, q7 = 7L;

my question is why padding on this sequence ? sequence is not an array , and once one cpu modified this value, value cached  in othere  cpus  will be invalid , it is not like the case  header and tail , if one cpu modified the header ,the filed tail will still keep valid, could some one tell me why doing this padding on sequence vaule?

[Michael Barker]

To prevent it accidentally sharing a cache line with some other piece of data so to reduce jitter as a result of false sharing.

--
You received this message because you are subscribed to the Google Groups "Disruptor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lmax-disruptor+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Terry Tan]

Hi mike,

As i know the cpu cache line is based on group work , which means the fields next to each other will not be allocated in the same cpu cache line , so if we do padding like this   private volatile long p1 = 7L, p2 = 7L, p3 = 7L, p4 = 7L, p5 = 7L, p6 = 7L, p7 = 7L,

                          value = Sequencer.INITIAL_CURSOR_VALUE,

                          q1 = 7L, q2 = 7L, q3 = 7L, q4 = 7L, q5 = 7L, q6 = 7L, q7 = 7L;

maybe in cpu cache line it will be like this 

cache line 1 :    p1  , p4, p7

cache line 2 :    value , p3, p6

cache line 3:     q1, q3,q5

...

....

cacheline 8:

rather than what you can see on the top 

cacheline 1 : p1, p2 ,......p7,value

cacheline 2 :  q1,q2..........q7

.....

how do we explain this thing?

mikeb01於 2018年3月2日星期五 UTC+8下午1時50分25秒寫道：

To unsubscribe from this group and stop receiving emails from it, send an email to lmax-disrupto...@googlegroups.com.

[Terry Tan]

Hi mike,

Sorry ,it is my misunderstanding, group means 64 bytes per one ,which means the one greater than 64 bytes ,let's say a new long field ,will be in another group ,the rest of the long fields will still be in the same group.

Terry Tan於 2018年4月10日星期二 UTC+8下午3時19分05秒寫道：

[Michael Barker]

I'm not 100% certain of the question that you are asking, but here is a guess at the response.

If you have a look at the implementation of Sequence you will notice the following:

class LhsPadding

{

    protected long p1, p2, p3, p4, p5, p6, p7;

}

class Value extends LhsPadding

{

    protected volatile long value;

}

class RhsPadding extends Value

{

    protected long p9, p10, p11, p12, p13, p14, p15;

}

public class Sequence extends RhsPadding

By placing the padding in an inheritance heirachy this prevents the compiler from reordering the fields across class boundaries.  Therefore we could see:

p1, p7, p4, p5, p6, p2, p3

value

p9, p11, p12, p10, p13, p14, p15

But won't see:

p1, 

value

p7, p4, p5, p6, p2, p3, p9, p11, p12, p10, p13, p14, p15

Laid out in memory, but there should always be 7 padded values either side of the real value.

Mike.

To unsubscribe from this group and stop receiving emails from it, send an email to lmax-disruptor+unsubscribe@googlegroups.com.