Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #117920
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Why volatile may make sense for parallel code today. |
| Date | 2023-11-23 12:50 -0500 |
| Organization | i2pn2 (i2pn.org) |
| Message-ID | <ujo3dr$1p192$1@i2pn2.org> (permalink) |
| References | (1 earlier) <ujlrdv$1g6ej$1@dont-email.me> <ujm5n6$1hok4$1@redfloyd.dont-email.me> <ujmmia$1nmms$1@dont-email.me> <ujntc3$1p191$1@i2pn2.org> <ujnu49$1t7eu$1@raubtier-asyl.eternal-september.org> |
On 11/23/23 11:20 AM, Bonita Montero wrote: > Am 23.11.2023 um 17:07 schrieb Richard Damon: > >> My understanding is that std:atomic needs to honor a read in the sense >> that it wlll get the most recent value that has happened "before" the >> read (as determined by memory order). > > ... and the read is atomic - even if the trivial object is 1kB in size. Yes, which has nothing to do with the question. > >> So, if nothing in the loop can establish a time order with respect to >> other threads, then it should be allowed for the compiler to optimize >> out the read. ... > > An atomic doesn't cache repeatable reads. The order memory-consistency > parameter is just for the ordering of other reads and writes. > Yes, the atomic itself doesn't "cache" the data, but as far as I read, there is no requirement to refetch the data if the code still has the old value around, and it hasn't been invalidated by possible memory ordering. If there can't be a write "before" the second read, that wasn't also also "after" the first read, then there is no requirement to refetch the data. In relaxed memory orders, just being physically before isn't enough to be "before", but you need some explicit "barrier" to establish it. I will admit this isn't an area I consider myself an expert in, but I find no words that prohibit the optimization. The implementation does need to consider possible action by other "threads" but only as far a constrained by memory order, so two reads in the same ordering "slot" are not forced.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-22 17:35 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-22 13:22 -0800
Re: Why volatile may make sense for parallel code today. red floyd <no.spam.here@its.invalid> - 2023-11-22 16:17 -0800
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-22 21:05 -0800
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-22 21:06 -0800
Re: Why volatile may make sense for parallel code today. Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-12-01 08:50 +0100
Re: Why volatile may make sense for parallel code today. David Brown <david.brown@hesbynett.no> - 2023-11-23 10:02 +0100
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-23 10:35 +0100
Re: Why volatile may make sense for parallel code today. scott@slp53.sl.home (Scott Lurndal) - 2023-11-23 19:55 +0000
Re: Why volatile may make sense for parallel code today. David Brown <david.brown@hesbynett.no> - 2023-11-24 10:08 +0100
Re: Why volatile may make sense for parallel code today. Richard Damon <richard@damon-family.org> - 2023-11-23 11:07 -0500
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-23 17:20 +0100
Re: Why volatile may make sense for parallel code today. Richard Damon <richard@damon-family.org> - 2023-11-23 12:50 -0500
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 08:57 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 00:16 -0800
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 09:30 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 01:04 -0800
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 01:05 -0800
Re: Why volatile may make sense for parallel code today. David Brown <david.brown@hesbynett.no> - 2023-11-24 10:23 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 22:05 -0800
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 22:53 -0800
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 08:53 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 01:06 -0800
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 10:10 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 01:14 -0800
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 15:32 -0800
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-23 08:08 +0100
Re: Why volatile may make sense for parallel code today. Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-23 08:26 +0000
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-23 09:31 +0100
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-23 15:39 +0100
Re: Why volatile may make sense for parallel code today. scott@slp53.sl.home (Scott Lurndal) - 2023-11-23 19:56 +0000
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 05:26 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 21:53 -0800
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 21:59 -0800
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 21:47 -0800
Re: Why volatile may make sense for parallel code today. Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-23 20:32 +0000
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 05:27 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 21:55 -0800
Re: Why volatile may make sense for parallel code today. David Brown <david.brown@hesbynett.no> - 2023-11-24 10:35 +0100
Re: Why volatile may make sense for parallel code today. Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-24 18:27 +0000
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 15:37 -0800
Re: Why volatile may make sense for parallel code today. Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-25 13:11 +0100
Re: Why volatile may make sense for parallel code today. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 14:46 -0800
csiph-web