X-Received: by 2002:a37:e55:: with SMTP id 82mr45935365qko.370.1577478877431; Fri, 27 Dec 2019 12:34:37 -0800 (PST)
X-Received: by 2002:a25:830e:: with SMTP id s14mr36904377ybk.265.1577478877238; Fri, 27 Dec 2019 12:34:37 -0800 (PST)
Path: csiph.com!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!g89no1914509qtd.0!news-out.google.com!o19ni41qtr.1!nntp.google.com!g89no1914502qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.programming.threads
Date: Fri, 27 Dec 2019 12:34:36 -0800 (PST)
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=24.200.162.29; posting-account=R-6XjwoAAACnHXTO3L-lyPW6wRsSmYW9
NNTP-Posting-Host: 24.200.162.29
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7cd5da84-cd7e-4046-aa4a-4eb525929a2d@googlegroups.com>
Subject: About the store buffer and memory visibility..
From: aminer68@gmail.com
Injection-Date: Fri, 27 Dec 2019 20:34:37 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 55
Xref: csiph.com comp.programming.threads:5428

Hello,


About the store buffer and memory visibility..


More about memory visibility..

I said before:

As you know that in parallel programming you have to take care=20
not only of memory ordering , but also take care about memory visibility, r=
ead this to notice it:

A store barrier, =E2=80=9Csfence=E2=80=9D instruction on x86, forces all st=
ore instructions prior to the barrier to happen before the barrier and have=
 the store buffers flushed to cache for the CPU on which it is issued.  Thi=
s will make the program state "visible" to other CPUs so they can act on it=
 if necessary. =20


Read more here to understand correctly:

"However under x86-TSO, the stores are cached in the store buffers,
a load consult only shared memory and the store buffer of the given thread,=
 wich means it can load data from memory and ignore values from=20
the other thread."

Read more here:

https://books.google.ca/books?id=3DC2R2DwAAQBAJ&pg=3DPA127&lpg=3DPA127&dq=
=3Dimmediately+visible+and+m+fence+and+store+buffer+and+x86&source=3Dbl&ots=
=3DyfGI17x1YZ&sig=3DACfU3U2EYRawTkQmi3s5wY-sM7IgowDlWg&hl=3Den&sa=3DX&ved=
=3D2ahUKEwi_nq3duYPkAhVDx1kKHYoyA5UQ6AEwAnoECAgQAQ#v=3Donepage&q=3Dimmediat=
ely%20visible%20and%20m%20fence%20and%20store%20buffer%20and%20x86&f=3Dfals=
e



Now can we ask the question of how much time takes the=20
store buffer to drain ?


So read here to notice:

https://nicknash.me/2018/04/07/speculating-about-store-buffer-capacity/


So as you are noticing he is giving around 500 no-ops to allow the store=20
buffer to drain, and i think that it can take less than that for the store =
buffer to drain.



Thank you,
Amine Moulay Ramdane.