[concurrency-interest] padding in Exchanger

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 17 09:49:02 EST 2012


It's not really a matter of more is better - you just need sufficient
padding to avoid two unrelated memory locations written by two different
cores being on the same cache line or else it'll cause excessive coherency
traffic.   Google "false sharing" for more info.
On Jan 17, 2012 9:42 AM, "Mohan Radhakrishnan" <
radhakrishnan.mohan at gmail.com> wrote:

> The more the padding the less the contention in cache. Is this the
> general idea apart from the calculation ?
>
> Thanks,
> Mohan
>
> On Tue, Jan 17, 2012 at 5:22 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> > On 01/17/12 06:39, Ruslan Cheremin wrote:
> >>
> >> My question is about cache-line padding in j.u.c.Exchanger.Slot class:
> >>
> >> private static final class Slot extends AtomicReference<Object>  {
> >>         // Improve likelihood of isolation on<= 64 byte cache lines
> >>         long q0, q1, q2, q3, q4, q5, q6, q7, q8, q9, qa, qb, qc, qd, qe;
> >> }
> >>
> >> Comments telling about<=64 byte cache line padding, but it seems for
> >> me what 15 longs*8 = 120 bytes (+8 bytes on object header, I suppose =
> >> even 128). Why to have 128 bytes padding for 64 byte cache line? It
> >> seems for me, what if I rely on one-side padding, I need only 7 longs
> >> (+header).
> >
> >
> > The short answer is that JVMs do not guarantee alignment.
> > For a longer answer, see the internals of the new Striped64 class at
> >
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/Striped64.java?view=log
> >
> > and/or the overhauled Exchanger class at
> >
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/Exchanger.java?view=log
> >
> > In general, especially on multisocket multicores these days,
> > you need to waste a lot of space to overcome crippling memory
> > contention effects that can easily slow down an application
> > by a factor of 4; sometimes more. Were trying to isolate
> > the cases where doing so is worthwhile inside libraries,
> > so that users don't need to think about it very often, so
> > long as they use the provided components.
> >
> > -Doug
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120117/5adfda21/attachment.html>


More information about the Concurrency-interest mailing list