Groups > comp.lang.c++ > #117907 > unrolled thread

Why volatile may make sense for parallel code today.

Started by	Bonita Montero <Bonita.Montero@gmail.com>
First post	2023-11-22 17:35 +0100
Last post	2023-11-25 14:46 -0800
Articles	20 on this page of 43 — 8 participants

Back to article view | Back to comp.lang.c++

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

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#117934

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-11-23 22:53 -0800
Message-ID	<ujph95$27qmb$1@dont-email.me>
In reply to	#117933

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

[toc] | [prev] | [next] | [standalone]

#117935

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2023-11-24 08:53 +0100
Message-ID	<ujpkq5$28aoq$1@raubtier-asyl.eternal-september.org>
In reply to	#117933

Am 24.11.2023 um 07:05 schrieb Chris M. Thomasson:

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

Read that:
https://stackoverflow.com/questions/61329240/what-is-the-difference-between-trivial-and-non-trivial-objects

[toc] | [prev] | [next] | [standalone]

#117943

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-11-24 01:06 -0800
Message-ID	<ujpp38$28srl$3@dont-email.me>
In reply to	#117935

On 11/23/2023 11:53 PM, Bonita Montero wrote:
> Am 24.11.2023 um 07:05 schrieb Chris M. Thomasson:
> 
>> 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?
> 
> Read that:
> https://stackoverflow.com/questions/61329240/what-is-the-difference-between-trivial-and-non-trivial-objects

I know. Btw, what the hell happened to std::is_pod? ;^)

[toc] | [prev] | [next] | [standalone]

#117945

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2023-11-24 10:10 +0100
Message-ID	<ujpp9d$28uis$1@raubtier-asyl.eternal-september.org>
In reply to	#117943

Am 24.11.2023 um 10:06 schrieb Chris M. Thomasson:
> On 11/23/2023 11:53 PM, Bonita Montero wrote:
>> Am 24.11.2023 um 07:05 schrieb Chris M. Thomasson:
>>
>>> 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?
>>
>> Read that:
>> https://stackoverflow.com/questions/61329240/what-is-the-difference-between-trivial-and-non-trivial-objects
> 
> I know. Btw, what the hell happened to std::is_pod? ;^)

PODs are also trivial but go beyond since you can copy them
with a memcpy():

[toc] | [prev] | [next] | [standalone]

#117946

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-11-24 01:14 -0800
Message-ID	<ujppgt$28srl$4@dont-email.me>
In reply to	#117919

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.

How is that read atomic with 1kb of data? On what arch?

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

[toc] | [prev] | [next] | [standalone]

#117956

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-11-24 15:32 -0800
Message-ID	<ujrbr8$2gjhg$1@dont-email.me>
In reply to	#117946

On 11/24/2023 1:14 AM, 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.
> 
> How is that read atomic with 1kb of data? On what arch?

Unless you atomically read a pointer that points to 1kB of memory.



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

[toc] | [prev] | [next] | [standalone]

#117912

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2023-11-23 08:08 +0100
Message-ID	<ujmtol$1ohl6$1@raubtier-asyl.eternal-september.org>
In reply to	#117908

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.

[toc] | [prev] | [next] | [standalone]

#117913

From	Kaz Kylheku <864-117-4973@kylheku.com>
Date	2023-11-23 08:26 +0000
Message-ID	<20231123001724.407@kylheku.com>
In reply to	#117912

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.

[toc] | [prev] | [next] | [standalone]

#117914

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2023-11-23 09:31 +0100
Message-ID	<ujn2ki$1p5nm$1@raubtier-asyl.eternal-september.org>
In reply to	#117913

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.

[toc] | [prev] | [next] | [standalone]

#117917

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2023-11-23 15:39 +0100
Message-ID	<ujno64$1s9v9$1@raubtier-asyl.eternal-september.org>
In reply to	#117914

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.

[toc] | [prev] | [next] | [standalone]

#117922

From	scott@slp53.sl.home (Scott Lurndal)
Date	2023-11-23 19:56 +0000
Message-ID	<L7O7N.94357$BbXa.57471@fx16.iad>
In reply to	#117912

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

[toc] | [prev] | [next] | [standalone]

#117925

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2023-11-24 05:26 +0100
Message-ID	<ujp8kr$26qm6$1@raubtier-asyl.eternal-september.org>
In reply to	#117922

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.

[toc] | [prev] | [next] | [standalone]

#117930

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-11-23 21:53 -0800
Message-ID	<ujpdoo$27c95$2@dont-email.me>
In reply to	#117925

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

[toc] | [prev] | [next] | [standalone]

#117932

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-11-23 21:59 -0800
Message-ID	<ujpe3m$27eto$1@dont-email.me>
In reply to	#117925

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!

[toc] | [prev] | [next] | [standalone]

#117929

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-11-23 21:47 -0800
Message-ID	<ujpdco$27c95$1@dont-email.me>
In reply to	#117922

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!

[toc] | [prev] | [next] | [standalone]

#117923

From	Kaz Kylheku <864-117-4973@kylheku.com>
Date	2023-11-23 20:32 +0000
Message-ID	<20231123120550.812@kylheku.com>
In reply to	#117907

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.

[toc] | [prev] | [next] | [standalone]

#117926

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2023-11-24 05:27 +0100
Message-ID	<ujp8n3$26qm6$2@raubtier-asyl.eternal-september.org>
In reply to	#117923

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.

[toc] | [prev] | [next] | [standalone]

#117931

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-11-23 21:55 -0800
Message-ID	<ujpds1$27c95$3@dont-email.me>
In reply to	#117926

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

[toc] | [prev] | [next] | [standalone]

#117951

From	David Brown <david.brown@hesbynett.no>
Date	2023-11-24 10:35 +0100
Message-ID	<ujpqpl$28uia$3@dont-email.me>
In reply to	#117926

On 24/11/2023 05:27, Bonita Montero wrote:

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

You really believe that?

I think one of the (many) reasons people don't take you seriously is 
that you never check your work.  You invariably post code that is badly 
wrong, followed by multiple replies to yourself making corrections and 
improvements.  Every time you claim your code is bug-free, we know you 
will follow up shortly with a bug fix.  Every time you claim it is 
"perfect", we know that you will follow it with an "improved" version 
("perfect" and "improved" being in your opinion only).

Yes, people have noticed.  Yes, people will continue to notice.

It's nice that you post code, however, as it can start some interesting 
discussions - before descending into a pantomime farce.  But it might 
make things a little better if you bothered to re-read your code before 
posting, or even try testing it.

[toc] | [prev] | [next] | [standalone]

#117954

From	Kaz Kylheku <864-117-4973@kylheku.com>
Date	2023-11-24 18:27 +0000
Message-ID	<20231124085003.476@kylheku.com>
In reply to	#117926

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

Anyway, this APC mechanism is quite similar to signal handling.
Particularly asynchronous signal handling. Just like POSIX signals, it
makes the execution abruptly call an unrelated function and then resume
at the interrupted point.

The main difference is that the signal has a number, which selects a
registered handler, rather than specifying a function directly.

Why I bring this up is that ISO C (since 1990, I think), has specified a
use of a "volatile sig_atomic_t" type in regard to asynchronous signal
handlers. (Look it up.)

The use of volatile with interrupt-like mechanisms is nothing new.

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

Why volatile may make sense for parallel code today.

Contents

#117934

#117935

#117943

#117945

#117946

#117956

#117912

#117913

#117914

#117917

#117922

#117925

#117930

#117932

#117929

#117923

#117926

#117931

#117951

#117954