Deutsch English Français Italiano |
<vhdn91$r246$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> Newsgroups: comp.arch Subject: Re: Memory ordering Date: Sun, 17 Nov 2024 13:30:10 -0800 Organization: A noiseless patient Spider Lines: 31 Message-ID: <vhdn91$r246$1@dont-email.me> References: <vfono1$14l9r$1@dont-email.me> <vgm4vj$3d2as$1@dont-email.me> <vgm5cb$3d2as$3@dont-email.me> <YfxXO.384093$EEm7.56154@fx16.iad> <vh4530$2mar5$1@dont-email.me> <-rKdnTO4LdoWXKj6nZ2dnZfqnPWdnZ2d@supernews.com> <vh5t5b$312cl$2@dont-email.me> <5yqdnU9eL_Y_GKv6nZ2dnZfqn_GdnZ2d@supernews.com> <2024Nov15.082512@mips.complang.tuwien.ac.at> <vh7ak1$3cm56$1@dont-email.me> <20241115152459.00004c86@yahoo.com> <vh8bn7$3j6ql$1@dont-email.me> <vhb2dc$73fe$1@dont-email.me> <vhct2q$lk1b$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 17 Nov 2024 22:30:10 +0100 (CET) Injection-Info: dont-email.me; posting-host="59b108c8b238722bb3d179b1acc0615e"; logging-data="886918"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+xOykMPcJmjTqKp+kcGinPIIGWLyqY/Wo=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:n6Wt+4wyuVkEsh/FAbSYfd2LfH0= Content-Language: en-US In-Reply-To: <vhct2q$lk1b$2@dont-email.me> Bytes: 2676 On 11/17/2024 6:03 AM, jseigh wrote: > On 11/16/24 16:21, Chris M. Thomasson wrote: > >> Fwiw, in C++ std::memory_order_consume is useful for traversing a node >> based stack of something in RCU. In most systems it only acts like a >> compiler barrier. On the Alpha, it must emit a membar instruction. >> Iirc, mb for alpha? Cannot remember that one right now. > > That got deprecated. Too hard for compilers to deal with. It's now > same as memory_order_acquire. Strange! C++ has: https://en.cppreference.com/w/cpp/atomic/atomic_signal_fence That only deals with compilers, not the arch memory order... Humm... Interesting Joe! > Which brings up an interesting point. Even if the hardware memory > memory model is strongly ordered, compilers can reorder stuff, > so you still have to program as if a weak memory model was in > effect. Or maybe disable reordering or optimization altogether > for those target architectures. Indeed. The compiler needs to know about these things. Iirc, there was an old post over c.p.t that deals with a compiler (think it was GCC) that messed up a pthread try lock for a mutex. It's a very old post. But I remember it for sure.