Deutsch English Français Italiano |
<vk22kr$31esr$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.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: Thu, 19 Dec 2024 13:19:24 -0800 Organization: A noiseless patient Spider Lines: 70 Message-ID: <vk22kr$31esr$1@dont-email.me> References: <vfono1$14l9r$1@dont-email.me> <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> <2024Nov17.161752@mips.complang.tuwien.ac.at> <vhh16e$1lp5h$1@dont-email.me> <2024Dec3.100144@mips.complang.tuwien.ac.at> <vin2rp$3ofc$1@dont-email.me> <3aa9f0a3d3dde86193abb1c01e52d03a@www.novabbs.org> <jwvser449xz.fsf-monnier+comp.arch@gnu.org> <vipv2t$v57m$1@dont-email.me> <virlki$1fhli$1@dont-email.me> <ad8ce8000ff1a5a708d3cca330b5861e@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 19 Dec 2024 22:19:25 +0100 (CET) Injection-Info: dont-email.me; posting-host="d7ca23497301f77098352327da5c83f3"; logging-data="3193755"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/0LgsfKR2Iy2ZmxFb5HWfRzT3UNcY5+f0=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:yEyTPNEbILvZXUGpA03GRqRuho0= In-Reply-To: <ad8ce8000ff1a5a708d3cca330b5861e@www.novabbs.org> Content-Language: en-US Bytes: 4441 On 12/19/2024 10:33 AM, MitchAlsup1 wrote: > On Thu, 5 Dec 2024 7:44:19 +0000, Chris M. Thomasson wrote: > >> On 12/4/2024 8:13 AM, jseigh wrote: >>> On 12/3/24 18:37, Stefan Monnier wrote: >>>>>> If there are places >>>>>> in the code it doesn't know this can't happen it won't optimize >>>>>> across it, more or less. >>>>> >>>>> The problem is HOW to TELL the COMPILER that these memory references >>>>> are "more special" than normal--when languages give few mechanisms. >>>> >>>> We could start with something like >>>> >>>> critical_region { >>>> ... >>>> } >>>> >>>> such that the compiler must refrain from any code motion within >>>> those sections but is free to move things outside of those sections as >>>> if >>>> execution was singlethreaded. >>>> >>> >>> C/C++11 already defines what lock acquire/release semantics are. >>> Roughly you can move stuff outside of a critical section into it >>> but not vice versa. >>> >>> Java uses synchronized blocks to denote the critical section. >>> C++ (the society for using RAII for everything) has scoped_lock >>> if you want to use RAII for your critical section. It's not >>> always obvious what the actual critical section is. I usually >>> use it inside its own bracket section to make it more obvious. >>> { std::scoped_lock m(mutex); >>> // .. critical section >>> } >>> >>> I'm not a big fan of c/c++ using acquire and release memory order >>> directives on everything since apart from a few situations it's >>> not intuitively obvious what they do in all cases. You can >>> look a compiler assembler output but you have to be real careful >>> generalizing from what you see. >> >> The release on the unlock can allow some following stores and things to >> sort of "bubble up before it? >> >> Acquire and release confines things to the "critical section", the >> release can allow for some following things to go above it, so to speak. >> This is making me think of Alex over on c.p.t. ! > > This sounds dangerous if the thing allowed to go above it is unCacheable > while the lock:release is cacheable, the cacheable lock can arrive at > another core before the unCacheable store arrives at its destination. Humm... Need to ponder on that. Wrt the sparc: membar #LoadStore | #StoreStore can allow following stores to bubble up before it. If we want to block that then we would use a #StoreLoad. However, a #StoreLoad is not required for unlocking a mutex. > >> :^) >> >> Did I miss anything? Sorry Joe.