Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #5428
| 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> (permalink) |
| 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 |
Show key headers only | View raw
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 not only of memory ordering , but also take care about memory visibility, read this to notice it: A store barrier, “sfence” instruction on x86, forces all store 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. This will make the program state "visible" to other CPUs so they can act on it if necessary. 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 the other thread." Read more here: https://books.google.ca/books?id=C2R2DwAAQBAJ&pg=PA127&lpg=PA127&dq=immediately+visible+and+m+fence+and+store+buffer+and+x86&source=bl&ots=yfGI17x1YZ&sig=ACfU3U2EYRawTkQmi3s5wY-sM7IgowDlWg&hl=en&sa=X&ved=2ahUKEwi_nq3duYPkAhVDx1kKHYoyA5UQ6AEwAnoECAgQAQ#v=onepage&q=immediately%20visible%20and%20m%20fence%20and%20store%20buffer%20and%20x86&f=false Now can we ask the question of how much time takes the 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 buffer to drain, and i think that it can take less than that for the store buffer to drain. Thank you, Amine Moulay Ramdane.
Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread
About the store buffer and memory visibility.. aminer68@gmail.com - 2019-12-27 12:34 -0800
csiph-web