Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #117915
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Why volatile may make sense for parallel code today. |
| Date | 2023-11-23 10:02 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <ujn4g3$1pevs$1@dont-email.me> (permalink) |
| References | <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org> <ujlrdv$1g6ej$1@dont-email.me> <ujm5n6$1hok4$1@redfloyd.dont-email.me> <ujmmia$1nmms$1@dont-email.me> |
On 23/11/2023 06:05, Chris M. Thomasson wrote:
> On 11/22/2023 4:17 PM, red floyd wrote:
>> On 11/22/2023 1:22 PM, Chris M. Thomasson wrote:
>>> On 11/22/2023 8:35 AM, Bonita Montero wrote:
>>>> #include <Windows.h>
>>>> #include <thread>
>>>>
>>>> using namespace std;
>>>>
>>>> int main()
>>>> {
>>>> constexpr size_t ROUNDS = 1'000'000;
>>>> size_t volatile r = 1'000'000;
>>>> jthread thr( [&]()
>>>> {
>>>> while( r )
>>>> SleepEx( INFINITE, TRUE );
>>>> } );
>>>> for( size_t r = ROUNDS; r--; )
>>>> QueueUserAPC( (PAPCFUNC)[]( auto p ) { --*(size_t*)p; },
>>>> thr.native_handle(), (ULONG_PTR)&r );
>>>> }
>>>
>>> std::atomic<size_t> r
>>>
>>
>> I'm confused. Does std:atomic imply "do not optimize access to this
>> variable"? Because if it doesn't, then I can see how the "while (r)"
>> loop can just spin.
>>
>>
>
> std::atomic should honor a read, when you read it even from
> std::memory_order_relaxed. If not, imvvvvhhooo, its broken?
You will probably find that compilers in practice will re-read "r" each
round of the loop, regardless of the memory order. I am not convinced
this would be required for "relaxed", but compilers generally do not
optimise atomics as much as they are allowed to. They are, as far as I
have seen in my far from comprehensive testing, treated as though
"atomic" implied "volatile".
But as far as I can tell from the C and C++ standards, "atomic" does not
imply "volatile". There are situations where atomics can be "optimised"
- re-ordered with respect to other code, or simplified - while volatile
atomics cannot. I can see no reason why adjacent non-volatile relaxed
atomic reads of the same object cannot be combined, even if separated by
other code (with no volatile or atomic accesses). The same goes for
writes. If you have :
std::atomic<int> ax = 100;
...
x = 1;
x += 2;
x = x * x;
then you are guaranteed that any other thread reading "ax" will see
either the old value (100, if it was not changed), or the final value of
9. It /might/ also see values of 1 or 3 along the way, but there is no
requirement for the code to produce these intermediate values or for
them to be visible to other threads.
At least, that is how I interpret things. And I believe the fact that
the C and C++ standards make a distinction between atomics and volatile
atomics indicates that the standard authors do not see "atomic" as
implying the semantics of "volatile" - even if compiler writers choose
to act that way.
I personally thing it was a terrible mistake to mix sequencing and
ordering with atomics when multi-threading was introduced to the C and
C++ standards. Atomics would have been simpler, more efficient, and
consistent with their naming if their semantics had not included any
kind of synchronisation. Synchronisation and ordering is a very
different concept from atomic access, and should be covered differently
(by fences of various sorts).
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