Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.iso-c++ > #2124
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Newsgroups | de.comp.lang.iso-c++ |
| Subject | Re: "Interessante" Richtungen für C++ |
| Date | 2019-10-21 18:09 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <qoks8t.4s4.1@stefan.msgid.phost.de> (permalink) |
| References | <qofg7a$e7a$1@newsreader4.netcologne.de> <qohcb0.4bc.1@stefan.msgid.phost.de> <qohnjd$587$1@news.albasani.net> |
Am 20.10.2019 um 15:31 schrieb Bonita Montero: >> Dass volatile irgendwie nicht zu gebrauchen ist, da gibt's aber auch >> ausreichend Tiraden von Linus Torvalds darüber. Insofern kann man da >> schon mal über Verbesserungen sprechen. Bei den anderen eher nicht so. > > volatile ist sehr wohl zu gebrauchen. Z.B. gibt es Heap-Allokatoren > wie jemalloc, TCMalloc oder mimalloc, die einen Pointer auf einen > Stack haben auf den andere Threads Speicher den diese freigeben per > locked compare & exchange draufpacken und die Threads denen der > Thread-lokale Heap gehört lesen diesen Wert ohne spezielle Art des > Zugiffs asynchron, rein darauf verlassend, dass volatile eben nur > bedeutet, dass volatile nicht mehr bedeutet als dass der Speicher- > zugriff nicht in einem Register gecacht werden darf. Dafür ist volatile weder hinreichend noch notwendig. Es sagt eben de facto nur, dass der Wert nicht in einem Register gecached werden darf. Es trifft aber keine Aussage darüber, wie der Wert zwischen den Caches eines Mehr-Kern-Rechners synchronisiert wird. Nicht alle Architekturen machen das implizit und transparent (MESI-Protokoll usw.). Was man eigentlich braucht ist std::atomic mit magischen Assembler- Instruktionen. Soweit mir bekannt werden diese eben für volatile nicht generiert. Und wenn man std::atomic mit load, store, exchange, compare_exchange_X hat, braucht man volatile nicht mehr. Stefan
Back to de.comp.lang.iso-c++ | Previous | Next — Previous in thread | Next in thread | Find similar
"Interessante" Richtungen für C++ Thomas Koenig <tkoenig@netcologne.de> - 2019-10-19 17:13 +0000
Re: "Interessante" Richtungen für C++ Florian Weimer <fw@deneb.enyo.de> - 2019-10-19 21:24 +0200
Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-06 16:39 +0200
Re: "Interessante" Richtungen für C++ Thomas Koenig <tkoenig@netcologne.de> - 2020-08-07 11:22 +0000
Re: "Interessante" Richtungen für C++ Florian Weimer <fw@deneb.enyo.de> - 2020-08-07 21:25 +0200
Re: "Interessante" Richtungen für C++ Thomas Koenig <tkoenig@netcologne.de> - 2020-08-15 08:34 +0000
Re: "Interessante" Richtungen für C++ Stefan Reuther <stefan.news@arcor.de> - 2019-10-20 10:19 +0200
Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-20 15:26 +0200
Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-20 15:31 +0200
Re: "Interessante" Richtungen für C++ Stefan Reuther <stefan.news@arcor.de> - 2019-10-21 18:09 +0200
Re: "Interessante" Richtungen für C++ Markus Schaaf <mschaaf@elaboris.de> - 2019-10-22 08:01 +0200
Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-08 10:41 +0200
Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-22 05:43 +0200
Re: "Interessante" Richtungen für C++ Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-10-21 20:36 +0200
Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-22 10:43 +0200
Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-22 12:55 +0200
Re: "Interessante" Richtungen für C++ Thomas Koenig <tkoenig@netcologne.de> - 2019-10-23 18:19 +0000
Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-08 14:47 +0200
csiph-web