Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #213

Re: False sharing

From Edek <edek.pienkowski@gmail.com>
Newsgroups comp.programming.threads
Subject Re: False sharing
Date 2011-05-31 20:10 +0200
Organization ATMAN - ATM S.A.
Message-ID <is3au3$lb8$1@node2.news.atman.pl> (permalink)
References <18fa2208-ba1c-42c5-bf1f-280e6cbc41e6@bl1g2000vbb.googlegroups.com> <is0un2$anb$1@node2.news.atman.pl> <eb6d6a69-ef08-4ebc-89dc-403886c3587f@24g2000yqk.googlegroups.com> <4de4f023$0$6568$9b4e6d93@newsspool3.arcor-online.net>

Show all headers | View raw


> curious wrote:
>> I was under the the understanding (most likely miss guided) that only
>> one CPU can have a cache line in modified state

With modern CPUs it is hard to tell, when exactly the data is in
"modified state". When the CPU knows the address, where it will store?
That plus what data is to be stored? That plus other writes, which are
write combined in the same cache line, or just pending? Cache lines
on the other hand have requests for ownership, they are well-defined.

(it should be invalid
>> at all others), when the another cpu tries to read the data from that
>> line it must be written and changed to exclusive state. This would
>> then cause so called cache line ping pong between the two competing
>> CPUs.
>
> This in an implementation detail. CPUs might also access cache lines of other CPUs via their interconnects. But this is slow too, although not that slow than a memory transfer.
>
>> Are you saying that the two CPUs can have two different modified
>> copies of the cache line that they keep updating?
>
> Definitely not.

.. but still, they may have two different copies of data at a
particular address, before L1 requests the rest of a cache line
to merge the changes. Intel Optimisation Guide says something about
the L1 waiting with RFO.

Edek

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

False sharing curious <curious.oskar58@gmail.com> - 2011-05-30 04:26 -0700
  Re: False sharing Edek <edek.pienkowski@gmail.com> - 2011-05-30 22:29 +0200
    Re: False sharing curious <curious.oskar58@gmail.com> - 2011-05-31 03:21 -0700
      Re: False sharing Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-05-31 15:41 +0200
        Re: False sharing curious <curious.oskar58@gmail.com> - 2011-05-31 10:18 -0700
        Re: False sharing Edek <edek.pienkowski@gmail.com> - 2011-05-31 20:10 +0200
      Re: False sharing Edek <edek.pienkowski@gmail.com> - 2011-05-31 20:37 +0200
        Re: False sharing Edek <edek.pienkowski@gmail.com> - 2011-05-31 21:18 +0200
          Re: False sharing curious <curious.oskar58@gmail.com> - 2011-05-31 14:40 -0700
            Re: False sharing "Balog Pal" <pasa@lib.hu> - 2011-06-01 03:17 +0200
            Re: False sharing Edek <edek.pienkowski@gmail.com> - 2011-06-01 22:20 +0200
        Re: False sharing curious <curious.oskar58@gmail.com> - 2011-05-31 14:29 -0700
  Re: False sharing David Schwartz <davids@webmaster.com> - 2011-05-31 14:12 -0700
  Re: False sharing "Chris M. Thomasson" <cristom@charter.net> - 2011-06-11 15:34 -0700
    Re: False sharing "Chris M. Thomasson" <cristom@charter.net> - 2011-06-11 19:56 -0700
      Re: False sharing "Chris M. Thomasson" <cristom@charter.net> - 2011-06-11 21:07 -0700

csiph-web