Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Turn on, tune up, rock out." -- Billy Gibbons


devel / comp.lang.c++ / Why volatile may make sense for parallel code today.

SubjectAuthor
* Why volatile may make sense for parallel code today.Bonita Montero
+* Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
|+* Re: Why volatile may make sense for parallel code today.red floyd
||`* Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
|| +* Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
|| |`- Re: Why volatile may make sense for parallel code today.Marcel Mueller
|| +* Re: Why volatile may make sense for parallel code today.David Brown
|| |+- Re: Why volatile may make sense for parallel code today.Bonita Montero
|| |`* Re: Why volatile may make sense for parallel code today.Scott Lurndal
|| | `- Re: Why volatile may make sense for parallel code today.David Brown
|| `* Re: Why volatile may make sense for parallel code today.Richard Damon
||  `* Re: Why volatile may make sense for parallel code today.Bonita Montero
||   +* Re: Why volatile may make sense for parallel code today.Richard Damon
||   |+* Re: Why volatile may make sense for parallel code today.Bonita Montero
||   ||`* Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
||   || `* Re: Why volatile may make sense for parallel code today.Bonita Montero
||   ||  `* Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
||   ||   `- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
||   |`- Re: Why volatile may make sense for parallel code today.David Brown
||   +* Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
||   |+- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
||   |`* Re: Why volatile may make sense for parallel code today.Bonita Montero
||   | `* Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
||   |  `- Re: Why volatile may make sense for parallel code today.Bonita Montero
||   `* Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
||    `- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
|`* Re: Why volatile may make sense for parallel code today.Bonita Montero
| +* Re: Why volatile may make sense for parallel code today.Kaz Kylheku
| |`* Re: Why volatile may make sense for parallel code today.Bonita Montero
| | `- Re: Why volatile may make sense for parallel code today.Bonita Montero
| `* Re: Why volatile may make sense for parallel code today.Scott Lurndal
|  +* Re: Why volatile may make sense for parallel code today.Bonita Montero
|  |+- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
|  |`- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
|  `- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
`* Re: Why volatile may make sense for parallel code today.Kaz Kylheku
 `* Re: Why volatile may make sense for parallel code today.Bonita Montero
  +- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
  +- Re: Why volatile may make sense for parallel code today.David Brown
  `* Re: Why volatile may make sense for parallel code today.Kaz Kylheku
   +- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson
   `* Re: Why volatile may make sense for parallel code today.Bonita Montero
    `- Re: Why volatile may make sense for parallel code today.Chris M. Thomasson

Pages:12
Why volatile may make sense for parallel code today.

<ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2739&group=comp.lang.c%2B%2B#2739

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!paganini.bofh.team!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Why volatile may make sense for parallel code today.
Date: Wed, 22 Nov 2023 17:35:08 +0100
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 22 Nov 2023 16:35:00 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="b4080d8fa655e82de8a8a6a8c0425384";
logging-data="1485489"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19g5lSRMonvL8rujrdqvc0q0l/vJP1Ufik="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:IBMfx/qVFMZgQy55pv18aWXFQLg=
Content-Language: de-DE
 by: Bonita Montero - Wed, 22 Nov 2023 16:35 UTC

#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 );
}

Re: Why volatile may make sense for parallel code today.

<ujlrdv$1g6ej$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2740&group=comp.lang.c%2B%2B#2740

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Wed, 22 Nov 2023 13:22:06 -0800
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <ujlrdv$1g6ej$1@dont-email.me>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 22 Nov 2023 21:22:07 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b8413604b88da726f65adfe382b85e83";
logging-data="1579475"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+erQznsaqRptWe7DtGVdk36ZJhNGNSqAI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:P453FJ/tWaptygyQAPXkPf/2VGM=
In-Reply-To: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
Content-Language: en-US
 by: Chris M. Thomasson - Wed, 22 Nov 2023 21:22 UTC

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

Re: Why volatile may make sense for parallel code today.

<ujm5n6$1hok4$1@redfloyd.dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2741&group=comp.lang.c%2B%2B#2741

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!redfloyd.dont-email.me!.POSTED!not-for-mail
From: no.spam....@its.invalid (red floyd)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Wed, 22 Nov 2023 16:17:40 -0800
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <ujm5n6$1hok4$1@redfloyd.dont-email.me>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 Nov 2023 00:17:42 -0000 (UTC)
Injection-Info: redfloyd.dont-email.me; posting-host="5d5d684817a71754ea296431b3275afe";
logging-data="1630852"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX191Ofq3LpkmJHAemJMGdCGcRQxTpwkcaHk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:DDT7driNbDfe+QV3nPiTvwa9r3s=
In-Reply-To: <ujlrdv$1g6ej$1@dont-email.me>
Content-Language: en-US
 by: red floyd - Thu, 23 Nov 2023 00:17 UTC

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.

Re: Why volatile may make sense for parallel code today.

<ujmmia$1nmms$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2742&group=comp.lang.c%2B%2B#2742

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!nntp.comgw.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Wed, 22 Nov 2023 21:05:13 -0800
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <ujmmia$1nmms$1@dont-email.me>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me> <ujm5n6$1hok4$1@redfloyd.dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 Nov 2023 05:05:14 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="cbc38f4a0bd3a53c236d0e587a7b3e98";
logging-data="1825500"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Fk3ADEuO7ORrz39eGY3pI9Khf6t/zfXE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:+mDkEy2BPp/LJEUjztM0RCVDk+s=
In-Reply-To: <ujm5n6$1hok4$1@redfloyd.dont-email.me>
Content-Language: en-US
 by: Chris M. Thomasson - Thu, 23 Nov 2023 05:05 UTC

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?

Re: Why volatile may make sense for parallel code today.

<ujmmki$1nmms$2@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2743&group=comp.lang.c%2B%2B#2743

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Wed, 22 Nov 2023 21:06:25 -0800
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <ujmmki$1nmms$2@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 Nov 2023 05:06:26 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="cbc38f4a0bd3a53c236d0e587a7b3e98";
logging-data="1825500"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+sRFG0wjx6ZuwuHytEfsWWs5bsuox0HBY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6diZv+dfDADFPFC6BnAuZHqsfNk=
Content-Language: en-US
In-Reply-To: <ujmmia$1nmms$1@dont-email.me>
 by: Chris M. Thomasson - Thu, 23 Nov 2023 05:06 UTC

On 11/22/2023 9:05 PM, 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?

Afaict, std::atomic should imply volatile? Right? If not, please correct me!

Re: Why volatile may make sense for parallel code today.

<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2744&group=comp.lang.c%2B%2B#2744

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 08:08:13 +0100
Organization: A noiseless patient Spider
Lines: 8
Message-ID: <ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Nov 2023 07:08:05 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="3ad17f6956cdfcf1fded0068b872def6";
logging-data="1853094"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/x1psTnsTRlasaLkBUwgLU88TC1D8NwZM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:YDqPog/J0loTu2n6hc68uhZnMtg=
In-Reply-To: <ujlrdv$1g6ej$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Thu, 23 Nov 2023 07:08 UTC

Am 22.11.2023 um 22:22 schrieb Chris M. Thomasson:

> std::atomic<size_t> r

The trick with my code is that the APC function is executed in the same
thread context as the function rpeatedly probing r as an end-indicator,
so I don't need atomic here. You should have known it better.

Re: Why volatile may make sense for parallel code today.

<20231123001724.407@kylheku.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2745&group=comp.lang.c%2B%2B#2745

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: 864-117-...@kylheku.com (Kaz Kylheku)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 08:26:39 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <20231123001724.407@kylheku.com>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
Injection-Date: Thu, 23 Nov 2023 08:26:39 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="ce1d5a66a2a3109b4edcaa847bb92b66";
logging-data="1870023"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/VwaqfamPV01NtMWECZ1Fxrvt0+dI61Ao="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:MQgXRyMdXIaNTK5sJsJWoFiunvQ=
 by: Kaz Kylheku - Thu, 23 Nov 2023 08:26 UTC

On 2023-11-23, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 22.11.2023 um 22:22 schrieb Chris M. Thomasson:
>
>> std::atomic<size_t> r
>
> The trick with my code is that the APC function is executed in the same
> thread context as the function rpeatedly probing r as an end-indicator,

So what is "parallel" doing your subject line?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Re: Why volatile may make sense for parallel code today.

<ujn2ki$1p5nm$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2746&group=comp.lang.c%2B%2B#2746

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 09:31:21 +0100
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <ujn2ki$1p5nm$1@raubtier-asyl.eternal-september.org>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
<20231123001724.407@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Nov 2023 08:31:14 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="3ad17f6956cdfcf1fded0068b872def6";
logging-data="1873654"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19tpAsSxsFJjr+I3og4cw4kcZ7d5EwENoE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cEjmPvzq95H0bScO39hGLknQSpI=
In-Reply-To: <20231123001724.407@kylheku.com>
Content-Language: de-DE
 by: Bonita Montero - Thu, 23 Nov 2023 08:31 UTC

Am 23.11.2023 um 09:26 schrieb Kaz Kylheku:
> On 2023-11-23, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 22.11.2023 um 22:22 schrieb Chris M. Thomasson:
>>
>>> std::atomic<size_t> r
>>
>> The trick with my code is that the APC function is executed in the same
>> thread context as the function rpeatedly probing r as an end-indicator,
>
> So what is "parallel" doing your subject line?

The parallel part is injecting the APC with QueueUserAPC().
Interestingly there's some framework-code calling the function object
which I use for the thread code that brings the thread into an alertable
state so that the loop never loops because r is already zero.

Re: Why volatile may make sense for parallel code today.

<ujn4g3$1pevs$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2747&group=comp.lang.c%2B%2B#2747

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!newsfeed.endofthelinebbs.com!news.hispagatos.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 10:02:58 +0100
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <ujn4g3$1pevs$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 Nov 2023 09:02:59 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="068e8032d3ea18ff735ab7986a109a9c";
logging-data="1883132"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+n+L3nXgaty3IMq03ZSX/yCbVEW2qOeFw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0
Cancel-Lock: sha1:FJZBx3k6fCgM4bb66Z7t8J9xD/g=
Content-Language: en-GB
In-Reply-To: <ujmmia$1nmms$1@dont-email.me>
 by: David Brown - Thu, 23 Nov 2023 09:02 UTC

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).

Re: Why volatile may make sense for parallel code today.

<ujn6d1$1pnpk$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2748&group=comp.lang.c%2B%2B#2748

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.neodome.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 10:35:36 +0100
Organization: A noiseless patient Spider
Lines: 8
Message-ID: <ujn6d1$1pnpk$1@raubtier-asyl.eternal-september.org>
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> <ujn4g3$1pevs$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Nov 2023 09:35:29 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="3ad17f6956cdfcf1fded0068b872def6";
logging-data="1892148"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+qbnM+Ox50v3AkCvtD97tI8u2HFtsp00o="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gbMj2sZG9/cfG/nklhrinnaQ3kg=
In-Reply-To: <ujn4g3$1pevs$1@dont-email.me>
Content-Language: de-DE
 by: Bonita Montero - Thu, 23 Nov 2023 09:35 UTC

Am 23.11.2023 um 10:02 schrieb David Brown:

> I am not convinced ....
> ... but compilers generally do not optimise atomics as much as they are allowed to.

Is there some kind of contradiction ?

Re: Why volatile may make sense for parallel code today.

<ujno64$1s9v9$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2749&group=comp.lang.c%2B%2B#2749

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.1d4.us!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 15:39:07 +0100
Organization: A noiseless patient Spider
Lines: 10
Message-ID: <ujno64$1s9v9$1@raubtier-asyl.eternal-september.org>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
<20231123001724.407@kylheku.com>
<ujn2ki$1p5nm$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Nov 2023 14:39:00 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="3ad17f6956cdfcf1fded0068b872def6";
logging-data="1976297"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/uVI9BGJDrunay8N1DvTDDeH02XIZWgm0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0QJFwq6Qo2sNQpGkeb3bPNjmO4c=
In-Reply-To: <ujn2ki$1p5nm$1@raubtier-asyl.eternal-september.org>
Content-Language: de-DE
 by: Bonita Montero - Thu, 23 Nov 2023 14:39 UTC

Am 23.11.2023 um 09:31 schrieb Bonita Montero:

> Interestingly there's some framework-code calling the function object
> which I use for the thread code that brings the thread into an alertable
> state so that the loop never loops because r is already zero.

It's for sure no framework code: I've checked the code with a Win32
thread created through CreateThread() and my APCs are eaten up before
the thread's main function runs. Really strange.

Re: Why volatile may make sense for parallel code today.

<ujntc3$1p191$1@i2pn2.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2750&group=comp.lang.c%2B%2B#2750

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!.POSTED!not-for-mail
From: rich...@damon-family.org (Richard Damon)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 11:07:31 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <ujntc3$1p191$1@i2pn2.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 Nov 2023 16:07:31 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="1869089"; mail-complaints-to="usenet@i2pn2.org";
posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <ujmmia$1nmms$1@dont-email.me>
 by: Richard Damon - Thu, 23 Nov 2023 16:07 UTC

On 11/23/23 12:05 AM, 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?

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).

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. SleepEx could (and should) establish time order, so the
compiler can't, in this case, optimize the read away.

Re: Why volatile may make sense for parallel code today.

<ujnu49$1t7eu$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2751&group=comp.lang.c%2B%2B#2751

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!rocksolid2!news.neodome.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 17:20:33 +0100
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <ujnu49$1t7eu$1@raubtier-asyl.eternal-september.org>
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> <ujntc3$1p191$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Nov 2023 16:20:25 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="3ad17f6956cdfcf1fded0068b872def6";
logging-data="2006494"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fGFXaKy691nxLo1kX1ZwrumPxZoKmtPQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:8bBXwBYincmig2fZHoP7P8hwC/w=
In-Reply-To: <ujntc3$1p191$1@i2pn2.org>
Content-Language: de-DE
 by: Bonita Montero - Thu, 23 Nov 2023 16:20 UTC

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.

> 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.

Re: Why volatile may make sense for parallel code today.

<ujo3dr$1p192$1@i2pn2.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2752&group=comp.lang.c%2B%2B#2752

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!.POSTED!not-for-mail
From: rich...@damon-family.org (Richard Damon)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 12:50:50 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <ujo3dr$1p192$1@i2pn2.org>
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> <ujntc3$1p191$1@i2pn2.org>
<ujnu49$1t7eu$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 Nov 2023 17:50:51 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="1869090"; mail-complaints-to="usenet@i2pn2.org";
posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <ujnu49$1t7eu$1@raubtier-asyl.eternal-september.org>
 by: Richard Damon - Thu, 23 Nov 2023 17:50 UTC

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.

Re: Why volatile may make sense for parallel code today.

<P6O7N.94356$BbXa.42252@fx16.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2753&group=comp.lang.c%2B%2B#2753

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!eternal-september.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Why volatile may make sense for parallel code today.
Newsgroups: comp.lang.c++
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> <ujn4g3$1pevs$1@dont-email.me>
Lines: 57
Message-ID: <P6O7N.94356$BbXa.42252@fx16.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Thu, 23 Nov 2023 19:55:27 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Thu, 23 Nov 2023 19:55:27 GMT
X-Received-Bytes: 2842
 by: Scott Lurndal - Thu, 23 Nov 2023 19:55 UTC

David Brown <david.brown@hesbynett.no> writes:
>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".

Linux tends to apply the volatile qualifier on the access, rather
than the definition.

#define ACCESS_ONCE(x) (*(volatile __typeof__(x) *)&(x))

while (ACCESS_ONCE(r)) {
}

Makes it rather obvious when reading the code what the intent
is, and won't be affected of someone accidentially removes the
volatile qualifier from the declaration of r.

Works just fine in c++, too.

Re: Why volatile may make sense for parallel code today.

<L7O7N.94357$BbXa.57471@fx16.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2754&group=comp.lang.c%2B%2B#2754

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.1d4.us!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Why volatile may make sense for parallel code today.
Newsgroups: comp.lang.c++
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org> <ujlrdv$1g6ej$1@dont-email.me> <ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
Lines: 8
Message-ID: <L7O7N.94357$BbXa.57471@fx16.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Thu, 23 Nov 2023 19:56:27 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Thu, 23 Nov 2023 19:56:27 GMT
X-Received-Bytes: 896
 by: Scott Lurndal - Thu, 23 Nov 2023 19:56 UTC

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 22.11.2023 um 22:22 schrieb Chris M. Thomasson:
>
>> std::atomic<size_t> r
>
>The trick with my code

That's enough to fail a job interview....

Re: Why volatile may make sense for parallel code today.

<20231123120550.812@kylheku.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2755&group=comp.lang.c%2B%2B#2755

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: 864-117-...@kylheku.com (Kaz Kylheku)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 20:32:33 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <20231123120550.812@kylheku.com>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
Injection-Date: Thu, 23 Nov 2023 20:32:33 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="ce1d5a66a2a3109b4edcaa847bb92b66";
logging-data="2083574"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+BRN6VliIeAiWj5KvdXeSFGSYxcDJNimM="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:9PF1Lx2w293r7f/OUL5r5+KKONw=
 by: Kaz Kylheku - Thu, 23 Nov 2023 20:32 UTC

On 2023-11-22, Bonita Montero <Bonita.Montero@gmail.com> 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--; )

This shadows the r variable. Did you mean "for (size_t i = ROUNDS; i--)"?

> QueueUserAPC( (PAPCFUNC)[]( auto p ) { --*(size_t*)p; },
> thr.native_handle(), (ULONG_PTR)&r );

Thus, this takes the address of the for loop's r variable, not the volatile one
that the thread is accessing. Is that what you wanted?

BTW, is the C++ lambda too broken to access the r via lexical scoping?
Why can't the APC just do "--r".

I believe local functions in Pascal from 1971 can do this.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Re: Why volatile may make sense for parallel code today.

<ujp8kr$26qm6$1@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2757&group=comp.lang.c%2B%2B#2757

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Fri, 24 Nov 2023 05:26:11 +0100
Organization: A noiseless patient Spider
Lines: 12
Message-ID: <ujp8kr$26qm6$1@raubtier-asyl.eternal-september.org>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
<L7O7N.94357$BbXa.57471@fx16.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Nov 2023 04:26:03 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="9ade70e49ca68ba2beb5a7fae8a1ed12";
logging-data="2321094"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/M8/KJFATQJLtfgstMDbij4h+kjeUkJOg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:mt9cD37LpdO3MAsrXT0oRh1e3VA=
Content-Language: de-DE
In-Reply-To: <L7O7N.94357$BbXa.57471@fx16.iad>
 by: Bonita Montero - Fri, 24 Nov 2023 04:26 UTC

Am 23.11.2023 um 20:56 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 22.11.2023 um 22:22 schrieb Chris M. Thomasson:
>>
>>> std::atomic<size_t> r
>>
>> The trick with my code

> That's enough to fail a job interview....

.... with a nerd like you.

Re: Why volatile may make sense for parallel code today.

<ujp8n3$26qm6$2@raubtier-asyl.eternal-september.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2758&group=comp.lang.c%2B%2B#2758

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail
From: Bonita.M...@gmail.com (Bonita Montero)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Fri, 24 Nov 2023 05:27:24 +0100
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <ujp8n3$26qm6$2@raubtier-asyl.eternal-september.org>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<20231123120550.812@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Nov 2023 04:27:15 -0000 (UTC)
Injection-Info: raubtier-asyl.eternal-september.org; posting-host="9ade70e49ca68ba2beb5a7fae8a1ed12";
logging-data="2321094"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19NWNn/2xIuaqxL4wd2CY5FaBG1leBDxLE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:dP2SUIB3IyXS6oE+ZUzaGAlUWkE=
In-Reply-To: <20231123120550.812@kylheku.com>
Content-Language: de-DE
 by: Bonita Montero - Fri, 24 Nov 2023 04:27 UTC

Am 23.11.2023 um 21:32 schrieb Kaz Kylheku:
> On 2023-11-22, Bonita Montero <Bonita.Montero@gmail.com> 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--; )
>
> This shadows the r variable. Did you mean "for (size_t i = ROUNDS; i--)"?
>
>> QueueUserAPC( (PAPCFUNC)[]( auto p ) { --*(size_t*)p; },
>> thr.native_handle(), (ULONG_PTR)&r );
>
> Thus, this takes the address of the for loop's r variable, not the volatile one
> that the thread is accessing. Is that what you wanted?
>
> BTW, is the C++ lambda too broken to access the r via lexical scoping?
> Why can't the APC just do "--r".
>
> I believe local functions in Pascal from 1971 can do this.
>

I already corrected that with my code and I guessed no one will notice
that here; usually I'm right with that.

Re: Why volatile may make sense for parallel code today.

<ujpdco$27c95$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2761&group=comp.lang.c%2B%2B#2761

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 21:47:03 -0800
Organization: A noiseless patient Spider
Lines: 11
Message-ID: <ujpdco$27c95$1@dont-email.me>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
<L7O7N.94357$BbXa.57471@fx16.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Nov 2023 05:47:05 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="7664f6b07543b36eac45e26755f90876";
logging-data="2339109"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/jdFGbmNr3eRWB1A/mKEE/rZj/SStqNwE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:VvYpM8CrMq/dTqvxX71wWXd59Lg=
Content-Language: en-US
In-Reply-To: <L7O7N.94357$BbXa.57471@fx16.iad>
 by: Chris M. Thomasson - Fri, 24 Nov 2023 05:47 UTC

On 11/23/2023 11:56 AM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 22.11.2023 um 22:22 schrieb Chris M. Thomasson:
>>
>>> std::atomic<size_t> r
>>
>> The trick with my code
>
> That's enough to fail a job interview....

Wow, no shit Scott. Yikes!

Re: Why volatile may make sense for parallel code today.

<ujpdoo$27c95$2@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2762&group=comp.lang.c%2B%2B#2762

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 21:53:27 -0800
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <ujpdoo$27c95$2@dont-email.me>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
<L7O7N.94357$BbXa.57471@fx16.iad>
<ujp8kr$26qm6$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Nov 2023 05:53:29 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="7664f6b07543b36eac45e26755f90876";
logging-data="2339109"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+gCwnRFArirK3PNtd3QZ15aPMVPcqssIc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:CN5bUG+i2eBv+bjNk/xxdXcJomg=
In-Reply-To: <ujp8kr$26qm6$1@raubtier-asyl.eternal-september.org>
Content-Language: en-US
 by: Chris M. Thomasson - Fri, 24 Nov 2023 05:53 UTC

On 11/23/2023 8:26 PM, Bonita Montero wrote:
> Am 23.11.2023 um 20:56 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 22.11.2023 um 22:22 schrieb Chris M. Thomasson:
>>>
>>>> std::atomic<size_t> r
>>>
>>> The trick with my code
>
>> That's enough to fail a job interview....
>
> ... with a nerd like you.
>

Huh? What does that even mean? Really, humm... ;^o

Re: Why volatile may make sense for parallel code today.

<ujpds1$27c95$3@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2763&group=comp.lang.c%2B%2B#2763

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.hispagatos.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 21:55:12 -0800
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <ujpds1$27c95$3@dont-email.me>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<20231123120550.812@kylheku.com>
<ujp8n3$26qm6$2@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 Nov 2023 05:55:13 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="7664f6b07543b36eac45e26755f90876";
logging-data="2339109"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19s0QtJFy8Fwu0Z0Qu+otHm4IfECL19d6E="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:e6h/Gp8qsrE+7mqgym4Ex/zAvK0=
Content-Language: en-US
In-Reply-To: <ujp8n3$26qm6$2@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Fri, 24 Nov 2023 05:55 UTC

On 11/23/2023 8:27 PM, Bonita Montero wrote:
> Am 23.11.2023 um 21:32 schrieb Kaz Kylheku:
>> On 2023-11-22, Bonita Montero <Bonita.Montero@gmail.com> 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--; )
>>
>> This shadows the r variable. Did you mean "for (size_t i = ROUNDS; i--)"?
>>
>>>         QueueUserAPC( (PAPCFUNC)[]( auto p ) { --*(size_t*)p; },
>>> thr.native_handle(), (ULONG_PTR)&r );
>>
>> Thus, this takes the address of the for loop's r variable, not the
>> volatile one
>> that the thread is accessing. Is that what you wanted?
>>
>> BTW, is the C++ lambda too broken to access the r via lexical scoping?
>> Why can't the APC just do "--r".
>>
>> I believe local functions in Pascal from 1971 can do this.
>>
>
> I already corrected that with my code and I guessed no one will notice
> that here; usually I'm right with that.
>

Usually, wrong, or always right? humm...

Re: Why volatile may make sense for parallel code today.

<ujpe3m$27eto$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2764&group=comp.lang.c%2B%2B#2764

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 21:59:17 -0800
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <ujpe3m$27eto$1@dont-email.me>
References: <ujlajk$1dalh$1@raubtier-asyl.eternal-september.org>
<ujlrdv$1g6ej$1@dont-email.me>
<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
<L7O7N.94357$BbXa.57471@fx16.iad>
<ujp8kr$26qm6$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Nov 2023 05:59:18 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="7664f6b07543b36eac45e26755f90876";
logging-data="2341816"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/4wnJXItIJsoh8u+wvasw1PFMlZzqTWb4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rv0P6TH7U+jQEdrjk/xZbx7ejlQ=
Content-Language: en-US
In-Reply-To: <ujp8kr$26qm6$1@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Fri, 24 Nov 2023 05:59 UTC

On 11/23/2023 8:26 PM, Bonita Montero wrote:
> Am 23.11.2023 um 20:56 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 22.11.2023 um 22:22 schrieb Chris M. Thomasson:
>>>
>>>> std::atomic<size_t> r
>>>
>>> The trick with my code
>
>> That's enough to fail a job interview....
>
> ... with a nerd like you.
>

Do you secretly like nerds? https://youtu.be/7dP1Vp1E-bo

lol!

Re: Why volatile may make sense for parallel code today.

<ujpefk$27eto$2@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2765&group=comp.lang.c%2B%2B#2765

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!news.1d4.us!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 22:05:39 -0800
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <ujpefk$27eto$2@dont-email.me>
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> <ujntc3$1p191$1@i2pn2.org>
<ujnu49$1t7eu$1@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Nov 2023 06:05:40 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="7664f6b07543b36eac45e26755f90876";
logging-data="2341816"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Al2aWdbwTSsKVnhf/pU4A8kJqKZ4fm/k="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:VFwiu3NEYjeWpzvSF49eMkCKgCU=
Content-Language: en-US
In-Reply-To: <ujnu49$1t7eu$1@raubtier-asyl.eternal-september.org>
 by: Chris M. Thomasson - Fri, 24 Nov 2023 06:05 UTC

On 11/23/2023 8: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.

humm.. Say, the read is from a word in memory. Define your trivial
object, POD, l2 cache line sized, and aligned on a l2 cache line
boundary? Are you refering to how certain arch works?

>
>> 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.
>
>
>

Re: Why volatile may make sense for parallel code today.

<ujph95$27qmb$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=2766&group=comp.lang.c%2B%2B#2766

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.network!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: Why volatile may make sense for parallel code today.
Date: Thu, 23 Nov 2023 22:53:24 -0800
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <ujph95$27qmb$1@dont-email.me>
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> <ujntc3$1p191$1@i2pn2.org>
<ujnu49$1t7eu$1@raubtier-asyl.eternal-september.org>
<ujpefk$27eto$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Nov 2023 06:53:25 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="7664f6b07543b36eac45e26755f90876";
logging-data="2353867"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cyrnxd0qyPF1W/StEckhFIJ91skHxUzU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:+Z0TLTwUKeSB1f4f/ltKswfREHo=
Content-Language: en-US
In-Reply-To: <ujpefk$27eto$2@dont-email.me>
 by: Chris M. Thomasson - Fri, 24 Nov 2023 06:53 UTC

On 11/23/2023 10:05 PM, Chris M. Thomasson wrote:
> On 11/23/2023 8: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.
>
> humm.. Say, the read is from a word in memory. Define your trivial
> object, POD, l2 cache line sized, and aligned on a l2 cache line
> boundary? Are you refering to how certain arch works?

How many words in your cache lines, say l2?

>
>>
>>> 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.
>>
>>
>>
>


devel / comp.lang.c++ / Why volatile may make sense for parallel code today.

Pages:12
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor