Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #120652 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2024-10-08 20:40 -0500 |
| Last post | 2024-11-30 10:03 -0500 |
| Articles | 20 on this page of 84 — 14 participants |
Back to article view | Back to comp.lang.c++
"Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-10-08 20:40 -0500
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-09 14:14 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-10-09 15:02 -0500
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-09 23:46 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 08:34 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 12:51 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 10:20 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 13:44 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 10:50 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 14:10 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 13:11 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 16:54 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-10 18:08 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-10-10 23:37 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-10 19:03 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 19:11 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" David Brown <david.brown@hesbynett.no> - 2024-10-10 20:01 +0200
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-10 07:56 -0700
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 18:56 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-10-20 10:13 -0700
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-10 12:13 -0400
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-10 18:29 +0200
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-20 12:37 +0100
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-20 14:46 +0300
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-20 14:23 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-27 19:09 -0400
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-27 20:40 -0400
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-10-28 09:22 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:18 -0700
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-28 12:25 -0400
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:56 -0400
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-30 12:50 -0700
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-30 16:31 -0400
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-04 12:47 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-07 07:02 -0500
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-11-07 20:14 -0600
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-08 09:40 -0500
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-08 14:48 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-08 14:54 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 12:40 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:39 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-11 09:56 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-11 13:36 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-12 08:28 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 13:56 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 13:59 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-12 16:20 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-10 13:02 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-10 13:05 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 12:46 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 05:18 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 13:23 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 05:25 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 13:27 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:02 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:09 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:35 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:37 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:47 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:58 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 07:09 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:35 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-08 23:50 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 18:11 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:39 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:58 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:01 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 07:13 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:40 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 08:19 +0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 18:15 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-09 16:23 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:42 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-09 23:23 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-10 11:00 +0200
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 16:56 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 16:59 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 17:05 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:50 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-04 06:59 -0800
Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-30 10:03 -0500
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 14:58 -0800 |
| Message-ID | <vgm528$3d2at$1@dont-email.me> |
| In reply to | #120858 |
On 11/8/2024 2:47 PM, wij wrote: > On Fri, 2024-11-08 at 14:37 -0800, Chris M. Thomasson wrote: >> On 11/8/2024 2:35 PM, wij wrote: >>> On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote: >>>> On 11/8/2024 2:02 PM, wij wrote: >>>>> On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote: >>>>>> On 11/8/2024 1:18 PM, wij wrote: >>>>>>> On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote: >>>>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>>>> On Fri, 08 Nov 2024 14:48:16 GMT >>>>>>>>> scott@slp53.sl.home (Scott Lurndal) boring babbled: >>>>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>>>>>>>>>> On 10/30/2024 11:56 AM, jseigh wrote: >>>>>>>>>>>> On 10/28/24 12:25, jseigh wrote: >>>>>>>>>>>> ... >>>>>>>>>>>>> The whole nullable pointer thing was a unrelated spin off of a >>>>>>>>>>>>> solution I did for addressing pointer provenance as discussed in >>>>>>>>>>>>> https://lwn.net/Articles/993484/ in the comments. >>>>>>>>>>>>> >>>>>>>>>>>>> The nullable pointer solution I proposed is not super clear >>>>>>>>>>>>> as it depends on behavior not presently in c++ so hard to >>>>>>>>>>>>> show how the solution would work. >>>>>>>>>>>>> >>>>>>>>>>>>> At any rate, I don't have problems with nullable pointers or >>>>>>>>>>>>> dealing with pointer provenance, and I don't have spare >>>>>>>>>>>>> cycles to implement solutions for the latter, solutions I >>>>>>>>>>>>> don't need. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I worked on this some more so I've gotten a better idea of >>>>>>>>>>>> what they mean by pointer provenance. I don't think will >>>>>>>>>>>> solve all the issues they think it will. I can come up >>>>>>>>>>>> with some pretty trivial examples that will break their >>>>>>>>>>>> proposed solutions. I think they are unicorn hunting here. >>>>>>>>>>>> >>>>>>>>>>>> One of the issues they brought up is the ABA problem. Yet >>>>>>>>>>>> C/C++ has abjectly refused to support 50 year old hardware >>>>>>>>>>>> features that would help for some ABA issues. Kind of hard >>>>>>>>>>>> to take the pointer provenance problem seriously. >>>>>>>>>>>> >>>>>>>>>>>> Joe Seigh >>>>>>>>>>> >>>>>>>>>>> What is the ABA problem ? >>>>>>>>>>> >>>>>>>>>>> Lynn >>>>>>>>>>> >>>>>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Why's it a problem? Its why mutexes exist. Why would anyone expect non >>>>>>>>> synchronised RW memory access to work? The exact same problem occurs >>>>>>>>> in databases with dirty reads. >>>>>>>> >>>>>>>> Humm... Not sure what to make of that comment. Have you ever >>>>>>>> experimented with lock-free algorithms? >>>>>>>> >>>>>>> >>>>>>> Why is it on topic? >>>>>>> >>>>>>> If "lock-free algorithms" is on topic, why just turn off multi-tasking? >>>>>>> >>>>>> >>>>>> I am not exactly sure what you mean by your question wrt "why just turn >>>>>> off multi-tasking"? Just use a single thread in your program? >>>>> >>>>> Yes, early threads are actually a single thread, where lock is not necessary. >>>> >>>> I am not sure what you mean by "early threads". Can you clarify a bit? >>>> Thanks. >>> >>> By early, I mean in DOS days. There was also such thread in Linux, I think it >>> is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking >>> >>>>> This remind me of a problem of the 'language'. Why we can't say: >>>>> >>>>> thread void f(Arg arg1); // 'thread' is keyword >>>>> >>>>> instead of lots of "weird" syntax, if we want to talk about "language"? >>>> >>>> C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin >>>> to PThreads. Well, minus the fine grain control we have wrt the "newer" >>>> standards... C++/C 11 and such. The DWCAS issue aside for a moment, its >>>> not all that bad. >>>> >>> >>> If so, use pthread to invent what you want, in stead of too many 'weird' modifications. >>> All are confined in your source. it should be easier to manage and less work and errors. >>> >> >> pthreads does not provide standard membars and atomics... C/C++11 does. > > I don't use std::atomic. I don't have memory I need it. > But I think using std::atomic and pthread is compatible (there might be 'language' problems > I don't know. Or it might be solvable). > Well, it might work wrt using std::atomic with pthreads. But, keep in mind that Pthreads does not know shit about std::atomic and vise versa.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 07:09 +0800 |
| Message-ID | <e6b8aaec798c94328990ea11e8ed04889396e4df.camel@gmail.com> |
| In reply to | #120859 |
On Fri, 2024-11-08 at 14:58 -0800, Chris M. Thomasson wrote: > On 11/8/2024 2:47 PM, wij wrote: > > On Fri, 2024-11-08 at 14:37 -0800, Chris M. Thomasson wrote: > > > On 11/8/2024 2:35 PM, wij wrote: > > > > On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote: > > > > > On 11/8/2024 2:02 PM, wij wrote: > > > > > > On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote: > > > > > > > On 11/8/2024 1:18 PM, wij wrote: > > > > > > > > On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote: > > > > > > > > > On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: > > > > > > > > > > On Fri, 08 Nov 2024 14:48:16 GMT > > > > > > > > > > scott@slp53.sl.home (Scott Lurndal) boring babbled: > > > > > > > > > > > Lynn McGuire <lynnmcguire5@gmail.com> writes: > > > > > > > > > > > > On 10/30/2024 11:56 AM, jseigh wrote: > > > > > > > > > > > > > On 10/28/24 12:25, jseigh wrote: > > > > > > > > > > > > > ... > > > > > > > > > > > > > > The whole nullable pointer thing was a unrelated spin off of a > > > > > > > > > > > > > > solution I did for addressing pointer provenance as discussed in > > > > > > > > > > > > > > https://lwn.net/Articles/993484/ in the comments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The nullable pointer solution I proposed is not super clear > > > > > > > > > > > > > > as it depends on behavior not presently in c++ so hard to > > > > > > > > > > > > > > show how the solution would work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > At any rate, I don't have problems with nullable pointers or > > > > > > > > > > > > > > dealing with pointer provenance, and I don't have spare > > > > > > > > > > > > > > cycles to implement solutions for the latter, solutions I > > > > > > > > > > > > > > don't need. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I worked on this some more so I've gotten a better idea of > > > > > > > > > > > > > what they mean by pointer provenance. I don't think will > > > > > > > > > > > > > solve all the issues they think it will. I can come up > > > > > > > > > > > > > with some pretty trivial examples that will break their > > > > > > > > > > > > > proposed solutions. I think they are unicorn hunting here. > > > > > > > > > > > > > > > > > > > > > > > > > > One of the issues they brought up is the ABA problem. Yet > > > > > > > > > > > > > C/C++ has abjectly refused to support 50 year old hardware > > > > > > > > > > > > > features that would help for some ABA issues. Kind of hard > > > > > > > > > > > > > to take the pointer provenance problem seriously. > > > > > > > > > > > > > > > > > > > > > > > > > > Joe Seigh > > > > > > > > > > > > > > > > > > > > > > > > What is the ABA problem ? > > > > > > > > > > > > > > > > > > > > > > > > Lynn > > > > > > > > > > > > > > > > > > > > > > > https://en.wikipedia.org/wiki/ABA_problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why's it a problem? Its why mutexes exist. Why would anyone expect non > > > > > > > > > > synchronised RW memory access to work? The exact same problem occurs > > > > > > > > > > in databases with dirty reads. > > > > > > > > > > > > > > > > > > Humm... Not sure what to make of that comment. Have you ever > > > > > > > > > experimented with lock-free algorithms? > > > > > > > > > > > > > > > > > > > > > > > > > Why is it on topic? > > > > > > > > > > > > > > > > If "lock-free algorithms" is on topic, why just turn off multi-tasking? > > > > > > > > > > > > > > > > > > > > > > I am not exactly sure what you mean by your question wrt "why just turn > > > > > > > off multi-tasking"? Just use a single thread in your program? > > > > > > > > > > > > Yes, early threads are actually a single thread, where lock is not necessary. > > > > > > > > > > I am not sure what you mean by "early threads". Can you clarify a bit? > > > > > Thanks. > > > > > > > > By early, I mean in DOS days. There was also such thread in Linux, I think it > > > > is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking > > > > > > > > > > This remind me of a problem of the 'language'. Why we can't say: > > > > > > > > > > > > thread void f(Arg arg1); // 'thread' is keyword > > > > > > > > > > > > instead of lots of "weird" syntax, if we want to talk about "language"? > > > > > > > > > > C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin > > > > > to PThreads. Well, minus the fine grain control we have wrt the "newer" > > > > > standards... C++/C 11 and such. The DWCAS issue aside for a moment, its > > > > > not all that bad. > > > > > > > > > > > > > If so, use pthread to invent what you want, in stead of too many 'weird' modifications. > > > > All are confined in your source. it should be easier to manage and less work and errors. > > > > > > > > > > pthreads does not provide standard membars and atomics... C/C++11 does. > > > > I don't use std::atomic. I don't have memory I need it. > > But I think using std::atomic and pthread is compatible (there might be 'language' problems > > I don't know. Or it might be solvable). > > > > Well, it might work wrt using std::atomic with pthreads. But, keep in > mind that Pthreads does not know shit about std::atomic and vise versa. As said I don't know std::atomic. But I know std::thread is a more abstract model which incorporates the functions of pthread. C++ in pthread is equivalent to C in pthread. C++ cannot behave differently.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 15:35 -0800 |
| Message-ID | <vgm77j$3dhh7$1@dont-email.me> |
| In reply to | #120862 |
On 11/8/2024 3:09 PM, wij wrote: > On Fri, 2024-11-08 at 14:58 -0800, Chris M. Thomasson wrote: >> On 11/8/2024 2:47 PM, wij wrote: >>> On Fri, 2024-11-08 at 14:37 -0800, Chris M. Thomasson wrote: >>>> On 11/8/2024 2:35 PM, wij wrote: >>>>> On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote: >>>>>> On 11/8/2024 2:02 PM, wij wrote: >>>>>>> On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote: >>>>>>>> On 11/8/2024 1:18 PM, wij wrote: >>>>>>>>> On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote: >>>>>>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>>>>>> On Fri, 08 Nov 2024 14:48:16 GMT >>>>>>>>>>> scott@slp53.sl.home (Scott Lurndal) boring babbled: >>>>>>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>>>>>>>>>>>> On 10/30/2024 11:56 AM, jseigh wrote: >>>>>>>>>>>>>> On 10/28/24 12:25, jseigh wrote: >>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> The whole nullable pointer thing was a unrelated spin off of a >>>>>>>>>>>>>>> solution I did for addressing pointer provenance as discussed in >>>>>>>>>>>>>>> https://lwn.net/Articles/993484/ in the comments. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The nullable pointer solution I proposed is not super clear >>>>>>>>>>>>>>> as it depends on behavior not presently in c++ so hard to >>>>>>>>>>>>>>> show how the solution would work. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At any rate, I don't have problems with nullable pointers or >>>>>>>>>>>>>>> dealing with pointer provenance, and I don't have spare >>>>>>>>>>>>>>> cycles to implement solutions for the latter, solutions I >>>>>>>>>>>>>>> don't need. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I worked on this some more so I've gotten a better idea of >>>>>>>>>>>>>> what they mean by pointer provenance. I don't think will >>>>>>>>>>>>>> solve all the issues they think it will. I can come up >>>>>>>>>>>>>> with some pretty trivial examples that will break their >>>>>>>>>>>>>> proposed solutions. I think they are unicorn hunting here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One of the issues they brought up is the ABA problem. Yet >>>>>>>>>>>>>> C/C++ has abjectly refused to support 50 year old hardware >>>>>>>>>>>>>> features that would help for some ABA issues. Kind of hard >>>>>>>>>>>>>> to take the pointer provenance problem seriously. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Joe Seigh >>>>>>>>>>>>> >>>>>>>>>>>>> What is the ABA problem ? >>>>>>>>>>>>> >>>>>>>>>>>>> Lynn >>>>>>>>>>>>> >>>>>>>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Why's it a problem? Its why mutexes exist. Why would anyone expect non >>>>>>>>>>> synchronised RW memory access to work? The exact same problem occurs >>>>>>>>>>> in databases with dirty reads. >>>>>>>>>> >>>>>>>>>> Humm... Not sure what to make of that comment. Have you ever >>>>>>>>>> experimented with lock-free algorithms? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Why is it on topic? >>>>>>>>> >>>>>>>>> If "lock-free algorithms" is on topic, why just turn off multi-tasking? >>>>>>>>> >>>>>>>> >>>>>>>> I am not exactly sure what you mean by your question wrt "why just turn >>>>>>>> off multi-tasking"? Just use a single thread in your program? >>>>>>> >>>>>>> Yes, early threads are actually a single thread, where lock is not necessary. >>>>>> >>>>>> I am not sure what you mean by "early threads". Can you clarify a bit? >>>>>> Thanks. >>>>> >>>>> By early, I mean in DOS days. There was also such thread in Linux, I think it >>>>> is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking >>>>> >>>>>>> This remind me of a problem of the 'language'. Why we can't say: >>>>>>> >>>>>>> thread void f(Arg arg1); // 'thread' is keyword >>>>>>> >>>>>>> instead of lots of "weird" syntax, if we want to talk about "language"? >>>>>> >>>>>> C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin >>>>>> to PThreads. Well, minus the fine grain control we have wrt the "newer" >>>>>> standards... C++/C 11 and such. The DWCAS issue aside for a moment, its >>>>>> not all that bad. >>>>>> >>>>> >>>>> If so, use pthread to invent what you want, in stead of too many 'weird' modifications. >>>>> All are confined in your source. it should be easier to manage and less work and errors. >>>>> >>>> >>>> pthreads does not provide standard membars and atomics... C/C++11 does. >>> >>> I don't use std::atomic. I don't have memory I need it. >>> But I think using std::atomic and pthread is compatible (there might be 'language' problems >>> I don't know. Or it might be solvable). >>> >> >> Well, it might work wrt using std::atomic with pthreads. But, keep in >> mind that Pthreads does not know shit about std::atomic and vise versa. > > As said I don't know std::atomic. But I know std::thread is a more abstract model which > incorporates the functions of pthread. C++ in pthread is equivalent to C in pthread. > C++ cannot behave differently. > The fun part about std::atomic and std::thread is that they are all in one standard. POSIX requires a compliant compiler and system. Iirc, std::atomic is not 100% guaranteed to work with PThreads. It does with std::threads...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-08 23:50 +0000 |
| Message-ID | <htxXO.384096$EEm7.146519@fx16.iad> |
| In reply to | #120864 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 11/8/2024 3:09 PM, wij wrote: > >The fun part about std::atomic and std::thread is that they are all in >one standard. POSIX requires a compliant compiler and system. Iirc, >std::atomic is not 100% guaranteed to work with PThreads. It does with >std::threads... If you're using pthreads, use POSIX synchronization APIs. If you're using C/C++ standard threads, use synchronization APIs defined by the standard. It's highly likely that on linux/unix systems, both sets of APIs are implemented using the same operating system primitives.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 18:11 -0800 |
| Message-ID | <vgmgd4$3epko$1@dont-email.me> |
| In reply to | #120866 |
On 11/8/2024 3:50 PM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 11/8/2024 3:09 PM, wij wrote: > >> >> The fun part about std::atomic and std::thread is that they are all in >> one standard. POSIX requires a compliant compiler and system. Iirc, >> std::atomic is not 100% guaranteed to work with PThreads. It does with >> std::threads... > > > If you're using pthreads, use POSIX synchronization APIs. Agreed. It's likely that std::atomic can be used in conjunction, but then again I am not 100% sure on that. Does the "contract" hold between std::atomic std::memory_order, ect... with POSIX threads? We know it does with std::thread and friends. > If you're using > C/C++ standard threads, use synchronization APIs defined by the standard. Agreed again. > It's highly likely that on linux/unix systems, both sets of APIs > are implemented using the same operating system primitives. Indeed.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 14:39 -0800 |
| Message-ID | <vgm3v0$3cunt$2@dont-email.me> |
| In reply to | #120855 |
On 11/8/2024 2:35 PM, wij wrote: > On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote: >> On 11/8/2024 2:02 PM, wij wrote: >>> On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote: >>>> On 11/8/2024 1:18 PM, wij wrote: >>>>> On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote: >>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>> On Fri, 08 Nov 2024 14:48:16 GMT >>>>>>> scott@slp53.sl.home (Scott Lurndal) boring babbled: >>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>>>>>>>> On 10/30/2024 11:56 AM, jseigh wrote: >>>>>>>>>> On 10/28/24 12:25, jseigh wrote: >>>>>>>>>> ... >>>>>>>>>>> The whole nullable pointer thing was a unrelated spin off of a >>>>>>>>>>> solution I did for addressing pointer provenance as discussed in >>>>>>>>>>> https://lwn.net/Articles/993484/ in the comments. >>>>>>>>>>> >>>>>>>>>>> The nullable pointer solution I proposed is not super clear >>>>>>>>>>> as it depends on behavior not presently in c++ so hard to >>>>>>>>>>> show how the solution would work. >>>>>>>>>>> >>>>>>>>>>> At any rate, I don't have problems with nullable pointers or >>>>>>>>>>> dealing with pointer provenance, and I don't have spare >>>>>>>>>>> cycles to implement solutions for the latter, solutions I >>>>>>>>>>> don't need. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I worked on this some more so I've gotten a better idea of >>>>>>>>>> what they mean by pointer provenance. I don't think will >>>>>>>>>> solve all the issues they think it will. I can come up >>>>>>>>>> with some pretty trivial examples that will break their >>>>>>>>>> proposed solutions. I think they are unicorn hunting here. >>>>>>>>>> >>>>>>>>>> One of the issues they brought up is the ABA problem. Yet >>>>>>>>>> C/C++ has abjectly refused to support 50 year old hardware >>>>>>>>>> features that would help for some ABA issues. Kind of hard >>>>>>>>>> to take the pointer provenance problem seriously. >>>>>>>>>> >>>>>>>>>> Joe Seigh >>>>>>>>> >>>>>>>>> What is the ABA problem ? >>>>>>>>> >>>>>>>>> Lynn >>>>>>>>> >>>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>>> >>>>>> >>>>>> >>>>>>> Why's it a problem? Its why mutexes exist. Why would anyone expect non >>>>>>> synchronised RW memory access to work? The exact same problem occurs >>>>>>> in databases with dirty reads. >>>>>> >>>>>> Humm... Not sure what to make of that comment. Have you ever >>>>>> experimented with lock-free algorithms? >>>>>> >>>>> >>>>> Why is it on topic? >>>>> >>>>> If "lock-free algorithms" is on topic, why just turn off multi-tasking? >>>>> >>>> >>>> I am not exactly sure what you mean by your question wrt "why just turn >>>> off multi-tasking"? Just use a single thread in your program? >>> >>> Yes, early threads are actually a single thread, where lock is not necessary. >> >> I am not sure what you mean by "early threads". Can you clarify a bit? >> Thanks. > > By early, I mean in DOS days. There was also such thread in Linux, I think it > is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking > >>> This remind me of a problem of the 'language'. Why we can't say: >>> >>> thread void f(Arg arg1); // 'thread' is keyword >>> >>> instead of lots of "weird" syntax, if we want to talk about "language"? >> >> C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin >> to PThreads. Well, minus the fine grain control we have wrt the "newer" >> standards... C++/C 11 and such. The DWCAS issue aside for a moment, its >> not all that bad. >> > > If so, use pthread to invent what you want, in stead of too many 'weird' modifications. > All are confined in your source. it should be easier to manage and less work and errors. > I used to use Pthreads all the time, and resort to asm for the lock-free bits... They were for pre C/C++11 impls. The damn DWCAS issue is annoying to say the least!
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 06:58 +0800 |
| Message-ID | <7497261e174d4bf72a9f049a4ca733da97e47c2b.camel@gmail.com> |
| In reply to | #120857 |
On Fri, 2024-11-08 at 14:39 -0800, Chris M. Thomasson wrote: > On 11/8/2024 2:35 PM, wij wrote: > > On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote: > > > On 11/8/2024 2:02 PM, wij wrote: > > > > On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote: > > > > > On 11/8/2024 1:18 PM, wij wrote: > > > > > > On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote: > > > > > > > On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: > > > > > > > > On Fri, 08 Nov 2024 14:48:16 GMT > > > > > > > > scott@slp53.sl.home (Scott Lurndal) boring babbled: > > > > > > > > > Lynn McGuire <lynnmcguire5@gmail.com> writes: > > > > > > > > > > On 10/30/2024 11:56 AM, jseigh wrote: > > > > > > > > > > > On 10/28/24 12:25, jseigh wrote: > > > > > > > > > > > ... > > > > > > > > > > > > The whole nullable pointer thing was a unrelated spin off of a > > > > > > > > > > > > solution I did for addressing pointer provenance as discussed in > > > > > > > > > > > > https://lwn.net/Articles/993484/ in the comments. > > > > > > > > > > > > > > > > > > > > > > > > The nullable pointer solution I proposed is not super clear > > > > > > > > > > > > as it depends on behavior not presently in c++ so hard to > > > > > > > > > > > > show how the solution would work. > > > > > > > > > > > > > > > > > > > > > > > > At any rate, I don't have problems with nullable pointers or > > > > > > > > > > > > dealing with pointer provenance, and I don't have spare > > > > > > > > > > > > cycles to implement solutions for the latter, solutions I > > > > > > > > > > > > don't need. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I worked on this some more so I've gotten a better idea of > > > > > > > > > > > what they mean by pointer provenance. I don't think will > > > > > > > > > > > solve all the issues they think it will. I can come up > > > > > > > > > > > with some pretty trivial examples that will break their > > > > > > > > > > > proposed solutions. I think they are unicorn hunting here. > > > > > > > > > > > > > > > > > > > > > > One of the issues they brought up is the ABA problem. Yet > > > > > > > > > > > C/C++ has abjectly refused to support 50 year old hardware > > > > > > > > > > > features that would help for some ABA issues. Kind of hard > > > > > > > > > > > to take the pointer provenance problem seriously. > > > > > > > > > > > > > > > > > > > > > > Joe Seigh > > > > > > > > > > > > > > > > > > > > What is the ABA problem ? > > > > > > > > > > > > > > > > > > > > Lynn > > > > > > > > > > > > > > > > > > > https://en.wikipedia.org/wiki/ABA_problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why's it a problem? Its why mutexes exist. Why would anyone expect non > > > > > > > > synchronised RW memory access to work? The exact same problem occurs > > > > > > > > in databases with dirty reads. > > > > > > > > > > > > > > Humm... Not sure what to make of that comment. Have you ever > > > > > > > experimented with lock-free algorithms? > > > > > > > > > > > > > > > > > > > Why is it on topic? > > > > > > > > > > > > If "lock-free algorithms" is on topic, why just turn off multi-tasking? > > > > > > > > > > > > > > > > I am not exactly sure what you mean by your question wrt "why just turn > > > > > off multi-tasking"? Just use a single thread in your program? > > > > > > > > Yes, early threads are actually a single thread, where lock is not necessary. > > > > > > I am not sure what you mean by "early threads". Can you clarify a bit? > > > Thanks. > > > > By early, I mean in DOS days. There was also such thread in Linux, I think it > > is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking > > > > > > This remind me of a problem of the 'language'. Why we can't say: > > > > > > > > thread void f(Arg arg1); // 'thread' is keyword > > > > > > > > instead of lots of "weird" syntax, if we want to talk about "language"? > > > > > > C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin > > > to PThreads. Well, minus the fine grain control we have wrt the "newer" > > > standards... C++/C 11 and such. The DWCAS issue aside for a moment, its > > > not all that bad. > > > > > > > If so, use pthread to invent what you want, in stead of too many 'weird' modifications. > > All are confined in your source. it should be easier to manage and less work and errors. > > > > I used to use Pthreads all the time, and resort to asm for the lock-free > bits... They were for pre C/C++11 impls. The damn DWCAS issue is > annoying to say the least! Sound like a good reason to invent your own Thread class. At least, you will know every thing more concrete.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 15:01 -0800 |
| Message-ID | <vgm58c$3d2as$2@dont-email.me> |
| In reply to | #120860 |
On 11/8/2024 2:58 PM, wij wrote: > On Fri, 2024-11-08 at 14:39 -0800, Chris M. Thomasson wrote: >> On 11/8/2024 2:35 PM, wij wrote: >>> On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote: >>>> On 11/8/2024 2:02 PM, wij wrote: >>>>> On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote: >>>>>> On 11/8/2024 1:18 PM, wij wrote: >>>>>>> On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote: >>>>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>>>> On Fri, 08 Nov 2024 14:48:16 GMT >>>>>>>>> scott@slp53.sl.home (Scott Lurndal) boring babbled: >>>>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>>>>>>>>>> On 10/30/2024 11:56 AM, jseigh wrote: >>>>>>>>>>>> On 10/28/24 12:25, jseigh wrote: >>>>>>>>>>>> ... >>>>>>>>>>>>> The whole nullable pointer thing was a unrelated spin off of a >>>>>>>>>>>>> solution I did for addressing pointer provenance as discussed in >>>>>>>>>>>>> https://lwn.net/Articles/993484/ in the comments. >>>>>>>>>>>>> >>>>>>>>>>>>> The nullable pointer solution I proposed is not super clear >>>>>>>>>>>>> as it depends on behavior not presently in c++ so hard to >>>>>>>>>>>>> show how the solution would work. >>>>>>>>>>>>> >>>>>>>>>>>>> At any rate, I don't have problems with nullable pointers or >>>>>>>>>>>>> dealing with pointer provenance, and I don't have spare >>>>>>>>>>>>> cycles to implement solutions for the latter, solutions I >>>>>>>>>>>>> don't need. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I worked on this some more so I've gotten a better idea of >>>>>>>>>>>> what they mean by pointer provenance. I don't think will >>>>>>>>>>>> solve all the issues they think it will. I can come up >>>>>>>>>>>> with some pretty trivial examples that will break their >>>>>>>>>>>> proposed solutions. I think they are unicorn hunting here. >>>>>>>>>>>> >>>>>>>>>>>> One of the issues they brought up is the ABA problem. Yet >>>>>>>>>>>> C/C++ has abjectly refused to support 50 year old hardware >>>>>>>>>>>> features that would help for some ABA issues. Kind of hard >>>>>>>>>>>> to take the pointer provenance problem seriously. >>>>>>>>>>>> >>>>>>>>>>>> Joe Seigh >>>>>>>>>>> >>>>>>>>>>> What is the ABA problem ? >>>>>>>>>>> >>>>>>>>>>> Lynn >>>>>>>>>>> >>>>>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Why's it a problem? Its why mutexes exist. Why would anyone expect non >>>>>>>>> synchronised RW memory access to work? The exact same problem occurs >>>>>>>>> in databases with dirty reads. >>>>>>>> >>>>>>>> Humm... Not sure what to make of that comment. Have you ever >>>>>>>> experimented with lock-free algorithms? >>>>>>>> >>>>>>> >>>>>>> Why is it on topic? >>>>>>> >>>>>>> If "lock-free algorithms" is on topic, why just turn off multi-tasking? >>>>>>> >>>>>> >>>>>> I am not exactly sure what you mean by your question wrt "why just turn >>>>>> off multi-tasking"? Just use a single thread in your program? >>>>> >>>>> Yes, early threads are actually a single thread, where lock is not necessary. >>>> >>>> I am not sure what you mean by "early threads". Can you clarify a bit? >>>> Thanks. >>> >>> By early, I mean in DOS days. There was also such thread in Linux, I think it >>> is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking >>> >>>>> This remind me of a problem of the 'language'. Why we can't say: >>>>> >>>>> thread void f(Arg arg1); // 'thread' is keyword >>>>> >>>>> instead of lots of "weird" syntax, if we want to talk about "language"? >>>> >>>> C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin >>>> to PThreads. Well, minus the fine grain control we have wrt the "newer" >>>> standards... C++/C 11 and such. The DWCAS issue aside for a moment, its >>>> not all that bad. >>>> >>> >>> If so, use pthread to invent what you want, in stead of too many 'weird' modifications. >>> All are confined in your source. it should be easier to manage and less work and errors. >>> >> >> I used to use Pthreads all the time, and resort to asm for the lock-free >> bits... They were for pre C/C++11 impls. The damn DWCAS issue is >> annoying to say the least! > > Sound like a good reason to invent your own Thread class. > At least, you will know every thing more concrete. > Well, wrt a thread class, just be sure to avoid calling into the thread logic before the ctor of your thread class is 100% completed. I have had to debug some really nasty bugs that dealt with that specific scenario. Yikes!
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 07:13 +0800 |
| Message-ID | <2416178fd919ab84364785af95abbb9d1623f98a.camel@gmail.com> |
| In reply to | #120861 |
On Fri, 2024-11-08 at 15:01 -0800, Chris M. Thomasson wrote: > On 11/8/2024 2:58 PM, wij wrote: > > On Fri, 2024-11-08 at 14:39 -0800, Chris M. Thomasson wrote: > > > On 11/8/2024 2:35 PM, wij wrote: > > > > On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote: > > > > > On 11/8/2024 2:02 PM, wij wrote: > > > > > > On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote: > > > > > > > On 11/8/2024 1:18 PM, wij wrote: > > > > > > > > On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote: > > > > > > > > > On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: > > > > > > > > > > On Fri, 08 Nov 2024 14:48:16 GMT > > > > > > > > > > scott@slp53.sl.home (Scott Lurndal) boring babbled: > > > > > > > > > > > Lynn McGuire <lynnmcguire5@gmail.com> writes: > > > > > > > > > > > > On 10/30/2024 11:56 AM, jseigh wrote: > > > > > > > > > > > > > On 10/28/24 12:25, jseigh wrote: > > > > > > > > > > > > > ... > > > > > > > > > > > > > > The whole nullable pointer thing was a unrelated spin off of a > > > > > > > > > > > > > > solution I did for addressing pointer provenance as discussed in > > > > > > > > > > > > > > https://lwn.net/Articles/993484/ in the comments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The nullable pointer solution I proposed is not super clear > > > > > > > > > > > > > > as it depends on behavior not presently in c++ so hard to > > > > > > > > > > > > > > show how the solution would work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > At any rate, I don't have problems with nullable pointers or > > > > > > > > > > > > > > dealing with pointer provenance, and I don't have spare > > > > > > > > > > > > > > cycles to implement solutions for the latter, solutions I > > > > > > > > > > > > > > don't need. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I worked on this some more so I've gotten a better idea of > > > > > > > > > > > > > what they mean by pointer provenance. I don't think will > > > > > > > > > > > > > solve all the issues they think it will. I can come up > > > > > > > > > > > > > with some pretty trivial examples that will break their > > > > > > > > > > > > > proposed solutions. I think they are unicorn hunting here. > > > > > > > > > > > > > > > > > > > > > > > > > > One of the issues they brought up is the ABA problem. Yet > > > > > > > > > > > > > C/C++ has abjectly refused to support 50 year old hardware > > > > > > > > > > > > > features that would help for some ABA issues. Kind of hard > > > > > > > > > > > > > to take the pointer provenance problem seriously. > > > > > > > > > > > > > > > > > > > > > > > > > > Joe Seigh > > > > > > > > > > > > > > > > > > > > > > > > What is the ABA problem ? > > > > > > > > > > > > > > > > > > > > > > > > Lynn > > > > > > > > > > > > > > > > > > > > > > > https://en.wikipedia.org/wiki/ABA_problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why's it a problem? Its why mutexes exist. Why would anyone expect non > > > > > > > > > > synchronised RW memory access to work? The exact same problem occurs > > > > > > > > > > in databases with dirty reads. > > > > > > > > > > > > > > > > > > Humm... Not sure what to make of that comment. Have you ever > > > > > > > > > experimented with lock-free algorithms? > > > > > > > > > > > > > > > > > > > > > > > > > Why is it on topic? > > > > > > > > > > > > > > > > If "lock-free algorithms" is on topic, why just turn off multi-tasking? > > > > > > > > > > > > > > > > > > > > > > I am not exactly sure what you mean by your question wrt "why just turn > > > > > > > off multi-tasking"? Just use a single thread in your program? > > > > > > > > > > > > Yes, early threads are actually a single thread, where lock is not necessary. > > > > > > > > > > I am not sure what you mean by "early threads". Can you clarify a bit? > > > > > Thanks. > > > > > > > > By early, I mean in DOS days. There was also such thread in Linux, I think it > > > > is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking > > > > > > > > > > This remind me of a problem of the 'language'. Why we can't say: > > > > > > > > > > > > thread void f(Arg arg1); // 'thread' is keyword > > > > > > > > > > > > instead of lots of "weird" syntax, if we want to talk about "language"? > > > > > > > > > > C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin > > > > > to PThreads. Well, minus the fine grain control we have wrt the "newer" > > > > > standards... C++/C 11 and such. The DWCAS issue aside for a moment, its > > > > > not all that bad. > > > > > > > > > > > > > If so, use pthread to invent what you want, in stead of too many 'weird' modifications. > > > > All are confined in your source. it should be easier to manage and less work and errors. > > > > > > > > > > I used to use Pthreads all the time, and resort to asm for the lock-free > > > bits... They were for pre C/C++11 impls. The damn DWCAS issue is > > > annoying to say the least! > > > > Sound like a good reason to invent your own Thread class. > > At least, you will know every thing more concrete. > > > > Well, wrt a thread class, just be sure to avoid calling into the thread > logic before the ctor of your thread class is 100% completed. I have had > to debug some really nasty bugs that dealt with that specific scenario. > Yikes! I need examples to understand what you mean. I have not touched thread issues for many years , but hope I can help.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 15:40 -0800 |
| Message-ID | <vgm7i1$3dhh7$2@dont-email.me> |
| In reply to | #120863 |
On 11/8/2024 3:13 PM, wij wrote: > On Fri, 2024-11-08 at 15:01 -0800, Chris M. Thomasson wrote: >> On 11/8/2024 2:58 PM, wij wrote: >>> On Fri, 2024-11-08 at 14:39 -0800, Chris M. Thomasson wrote: >>>> On 11/8/2024 2:35 PM, wij wrote: >>>>> On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote: >>>>>> On 11/8/2024 2:02 PM, wij wrote: >>>>>>> On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote: >>>>>>>> On 11/8/2024 1:18 PM, wij wrote: >>>>>>>>> On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote: >>>>>>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>>>>>> On Fri, 08 Nov 2024 14:48:16 GMT >>>>>>>>>>> scott@slp53.sl.home (Scott Lurndal) boring babbled: >>>>>>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>>>>>>>>>>>> On 10/30/2024 11:56 AM, jseigh wrote: >>>>>>>>>>>>>> On 10/28/24 12:25, jseigh wrote: >>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> The whole nullable pointer thing was a unrelated spin off of a >>>>>>>>>>>>>>> solution I did for addressing pointer provenance as discussed in >>>>>>>>>>>>>>> https://lwn.net/Articles/993484/ in the comments. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The nullable pointer solution I proposed is not super clear >>>>>>>>>>>>>>> as it depends on behavior not presently in c++ so hard to >>>>>>>>>>>>>>> show how the solution would work. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At any rate, I don't have problems with nullable pointers or >>>>>>>>>>>>>>> dealing with pointer provenance, and I don't have spare >>>>>>>>>>>>>>> cycles to implement solutions for the latter, solutions I >>>>>>>>>>>>>>> don't need. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I worked on this some more so I've gotten a better idea of >>>>>>>>>>>>>> what they mean by pointer provenance. I don't think will >>>>>>>>>>>>>> solve all the issues they think it will. I can come up >>>>>>>>>>>>>> with some pretty trivial examples that will break their >>>>>>>>>>>>>> proposed solutions. I think they are unicorn hunting here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One of the issues they brought up is the ABA problem. Yet >>>>>>>>>>>>>> C/C++ has abjectly refused to support 50 year old hardware >>>>>>>>>>>>>> features that would help for some ABA issues. Kind of hard >>>>>>>>>>>>>> to take the pointer provenance problem seriously. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Joe Seigh >>>>>>>>>>>>> >>>>>>>>>>>>> What is the ABA problem ? >>>>>>>>>>>>> >>>>>>>>>>>>> Lynn >>>>>>>>>>>>> >>>>>>>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Why's it a problem? Its why mutexes exist. Why would anyone expect non >>>>>>>>>>> synchronised RW memory access to work? The exact same problem occurs >>>>>>>>>>> in databases with dirty reads. >>>>>>>>>> >>>>>>>>>> Humm... Not sure what to make of that comment. Have you ever >>>>>>>>>> experimented with lock-free algorithms? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Why is it on topic? >>>>>>>>> >>>>>>>>> If "lock-free algorithms" is on topic, why just turn off multi-tasking? >>>>>>>>> >>>>>>>> >>>>>>>> I am not exactly sure what you mean by your question wrt "why just turn >>>>>>>> off multi-tasking"? Just use a single thread in your program? >>>>>>> >>>>>>> Yes, early threads are actually a single thread, where lock is not necessary. >>>>>> >>>>>> I am not sure what you mean by "early threads". Can you clarify a bit? >>>>>> Thanks. >>>>> >>>>> By early, I mean in DOS days. There was also such thread in Linux, I think it >>>>> is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking >>>>> >>>>>>> This remind me of a problem of the 'language'. Why we can't say: >>>>>>> >>>>>>> thread void f(Arg arg1); // 'thread' is keyword >>>>>>> >>>>>>> instead of lots of "weird" syntax, if we want to talk about "language"? >>>>>> >>>>>> C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin >>>>>> to PThreads. Well, minus the fine grain control we have wrt the "newer" >>>>>> standards... C++/C 11 and such. The DWCAS issue aside for a moment, its >>>>>> not all that bad. >>>>>> >>>>> >>>>> If so, use pthread to invent what you want, in stead of too many 'weird' modifications. >>>>> All are confined in your source. it should be easier to manage and less work and errors. >>>>> >>>> >>>> I used to use Pthreads all the time, and resort to asm for the lock-free >>>> bits... They were for pre C/C++11 impls. The damn DWCAS issue is >>>> annoying to say the least! >>> >>> Sound like a good reason to invent your own Thread class. >>> At least, you will know every thing more concrete. >>> >> >> Well, wrt a thread class, just be sure to avoid calling into the thread >> logic before the ctor of your thread class is 100% completed. I have had >> to debug some really nasty bugs that dealt with that specific scenario. >> Yikes! > > I need examples to understand what you mean. I have not touched thread issues for many years > , but hope I can help. > iirc, it was a base class that called its pure virtual thread entry function _before_ its derived class had a chance to fully complete its ctor. It's been a while since I have encountered this nasty scenario. Thank god.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 08:19 +0800 |
| Message-ID | <7b15ad076f2ce8bae6b194057f8215ee634d6c2a.camel@gmail.com> |
| In reply to | #120865 |
On Fri, 2024-11-08 at 15:40 -0800, Chris M. Thomasson wrote:
> On 11/8/2024 3:13 PM, wij wrote:
> > On Fri, 2024-11-08 at 15:01 -0800, Chris M. Thomasson wrote:
> > > On 11/8/2024 2:58 PM, wij wrote:
> > > > On Fri, 2024-11-08 at 14:39 -0800, Chris M. Thomasson wrote:
> > > > > On 11/8/2024 2:35 PM, wij wrote:
> > > > > > On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote:
> > > > > > > On 11/8/2024 2:02 PM, wij wrote:
> > > > > > > > On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote:
> > > > > > > > > On 11/8/2024 1:18 PM, wij wrote:
> > > > > > > > > > On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote:
> > > > > > > > > > > On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote:
> > > > > > > > > > > > On Fri, 08 Nov 2024 14:48:16 GMT
> > > > > > > > > > > > scott@slp53.sl.home (Scott Lurndal) boring babbled:
> > > > > > > > > > > > > Lynn McGuire <lynnmcguire5@gmail.com> writes:
> > > > > > > > > > > > > > On 10/30/2024 11:56 AM, jseigh wrote:
> > > > > > > > > > > > > > > On 10/28/24 12:25, jseigh wrote:
> > > > > > > > > > > > > > > ...
> > > > > > > > > > > > > > > > The whole nullable pointer thing was a unrelated spin off of a
> > > > > > > > > > > > > > > > solution I did for addressing pointer provenance as discussed in
> > > > > > > > > > > > > > > > https://lwn.net/Articles/993484/ in the comments.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The nullable pointer solution I proposed is not super clear
> > > > > > > > > > > > > > > > as it depends on behavior not presently in c++ so hard to
> > > > > > > > > > > > > > > > show how the solution would work.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > At any rate, I don't have problems with nullable pointers or
> > > > > > > > > > > > > > > > dealing with pointer provenance, and I don't have spare
> > > > > > > > > > > > > > > > cycles to implement solutions for the latter, solutions I
> > > > > > > > > > > > > > > > don't need.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I worked on this some more so I've gotten a better idea of
> > > > > > > > > > > > > > > what they mean by pointer provenance. I don't think will
> > > > > > > > > > > > > > > solve all the issues they think it will. I can come up
> > > > > > > > > > > > > > > with some pretty trivial examples that will break their
> > > > > > > > > > > > > > > proposed solutions. I think they are unicorn hunting here.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > One of the issues they brought up is the ABA problem. Yet
> > > > > > > > > > > > > > > C/C++ has abjectly refused to support 50 year old hardware
> > > > > > > > > > > > > > > features that would help for some ABA issues. Kind of hard
> > > > > > > > > > > > > > > to take the pointer provenance problem seriously.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Joe Seigh
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > What is the ABA problem ?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Lynn
> > > > > > > > > > > > > >
> > > > > > > > > > > > > https://en.wikipedia.org/wiki/ABA_problem
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Why's it a problem? Its why mutexes exist. Why would anyone expect non
> > > > > > > > > > > > synchronised RW memory access to work? The exact same problem occurs
> > > > > > > > > > > > in databases with dirty reads.
> > > > > > > > > > >
> > > > > > > > > > > Humm... Not sure what to make of that comment. Have you ever
> > > > > > > > > > > experimented with lock-free algorithms?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Why is it on topic?
> > > > > > > > > >
> > > > > > > > > > If "lock-free algorithms" is on topic, why just turn off multi-tasking?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I am not exactly sure what you mean by your question wrt "why just turn
> > > > > > > > > off multi-tasking"? Just use a single thread in your program?
> > > > > > > >
> > > > > > > > Yes, early threads are actually a single thread, where lock is not necessary.
> > > > > > >
> > > > > > > I am not sure what you mean by "early threads". Can you clarify a bit?
> > > > > > > Thanks.
> > > > > >
> > > > > > By early, I mean in DOS days. There was also such thread in Linux, I think it
> > > > > > is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
> > > > > >
> > > > > > > > This remind me of a problem of the 'language'. Why we can't say:
> > > > > > > >
> > > > > > > > thread void f(Arg arg1); // 'thread' is keyword
> > > > > > > >
> > > > > > > > instead of lots of "weird" syntax, if we want to talk about "language"?
> > > > > > >
> > > > > > > C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
> > > > > > > to PThreads. Well, minus the fine grain control we have wrt the "newer"
> > > > > > > standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
> > > > > > > not all that bad.
> > > > > > >
> > > > > >
> > > > > > If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
> > > > > > All are confined in your source. it should be easier to manage and less work and errors.
> > > > > >
> > > > >
> > > > > I used to use Pthreads all the time, and resort to asm for the lock-free
> > > > > bits... They were for pre C/C++11 impls. The damn DWCAS issue is
> > > > > annoying to say the least!
> > > >
> > > > Sound like a good reason to invent your own Thread class.
> > > > At least, you will know every thing more concrete.
> > > >
> > >
> > > Well, wrt a thread class, just be sure to avoid calling into the thread
> > > logic before the ctor of your thread class is 100% completed. I have had
> > > to debug some really nasty bugs that dealt with that specific scenario.
> > > Yikes!
> >
> > I need examples to understand what you mean. I have not touched thread issues for many years
> > , but hope I can help.
> >
>
> iirc, it was a base class that called its pure virtual thread entry
> function _before_ its derived class had a chance to fully complete its
> ctor. It's been a while since I have encountered this nasty scenario.
> Thank god.
class BaseThread {
public:
BaseThread(Func func);
virtual ~BaseThread();
};
class Thread : BaseThread {
public:
Thread(Func func) {
// init vars.
::pthread_create(...func...); // the last line
};
// ....
}
The thread should be started in Thread (not in BaseThread), if I guess what you mean correctly.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 18:15 -0800 |
| Message-ID | <vgmgkb$3epko$2@dont-email.me> |
| In reply to | #120867 |
On 11/8/2024 4:19 PM, wij wrote:
> On Fri, 2024-11-08 at 15:40 -0800, Chris M. Thomasson wrote:
>> On 11/8/2024 3:13 PM, wij wrote:
>>> On Fri, 2024-11-08 at 15:01 -0800, Chris M. Thomasson wrote:
>>>> On 11/8/2024 2:58 PM, wij wrote:
>>>>> On Fri, 2024-11-08 at 14:39 -0800, Chris M. Thomasson wrote:
>>>>>> On 11/8/2024 2:35 PM, wij wrote:
>>>>>>> On Fri, 2024-11-08 at 14:09 -0800, Chris M. Thomasson wrote:
>>>>>>>> On 11/8/2024 2:02 PM, wij wrote:
>>>>>>>>> On Fri, 2024-11-08 at 13:27 -0800, Chris M. Thomasson wrote:
>>>>>>>>>> On 11/8/2024 1:18 PM, wij wrote:
>>>>>>>>>>> On Fri, 2024-11-08 at 12:46 -0800, Chris M. Thomasson wrote:
>>>>>>>>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote:
>>>>>>>>>>>>> On Fri, 08 Nov 2024 14:48:16 GMT
>>>>>>>>>>>>> scott@slp53.sl.home (Scott Lurndal) boring babbled:
>>>>>>>>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>>>>>>>>>>>>> On 10/30/2024 11:56 AM, jseigh wrote:
>>>>>>>>>>>>>>>> On 10/28/24 12:25, jseigh wrote:
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>> The whole nullable pointer thing was a unrelated spin off of a
>>>>>>>>>>>>>>>>> solution I did for addressing pointer provenance as discussed in
>>>>>>>>>>>>>>>>> https://lwn.net/Articles/993484/ in the comments.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The nullable pointer solution I proposed is not super clear
>>>>>>>>>>>>>>>>> as it depends on behavior not presently in c++ so hard to
>>>>>>>>>>>>>>>>> show how the solution would work.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> At any rate, I don't have problems with nullable pointers or
>>>>>>>>>>>>>>>>> dealing with pointer provenance, and I don't have spare
>>>>>>>>>>>>>>>>> cycles to implement solutions for the latter, solutions I
>>>>>>>>>>>>>>>>> don't need.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I worked on this some more so I've gotten a better idea of
>>>>>>>>>>>>>>>> what they mean by pointer provenance. I don't think will
>>>>>>>>>>>>>>>> solve all the issues they think it will. I can come up
>>>>>>>>>>>>>>>> with some pretty trivial examples that will break their
>>>>>>>>>>>>>>>> proposed solutions. I think they are unicorn hunting here.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One of the issues they brought up is the ABA problem. Yet
>>>>>>>>>>>>>>>> C/C++ has abjectly refused to support 50 year old hardware
>>>>>>>>>>>>>>>> features that would help for some ABA issues. Kind of hard
>>>>>>>>>>>>>>>> to take the pointer provenance problem seriously.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Joe Seigh
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What is the ABA problem ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lynn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/ABA_problem
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Why's it a problem? Its why mutexes exist. Why would anyone expect non
>>>>>>>>>>>>> synchronised RW memory access to work? The exact same problem occurs
>>>>>>>>>>>>> in databases with dirty reads.
>>>>>>>>>>>>
>>>>>>>>>>>> Humm... Not sure what to make of that comment. Have you ever
>>>>>>>>>>>> experimented with lock-free algorithms?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Why is it on topic?
>>>>>>>>>>>
>>>>>>>>>>> If "lock-free algorithms" is on topic, why just turn off multi-tasking?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am not exactly sure what you mean by your question wrt "why just turn
>>>>>>>>>> off multi-tasking"? Just use a single thread in your program?
>>>>>>>>>
>>>>>>>>> Yes, early threads are actually a single thread, where lock is not necessary.
>>>>>>>>
>>>>>>>> I am not sure what you mean by "early threads". Can you clarify a bit?
>>>>>>>> Thanks.
>>>>>>>
>>>>>>> By early, I mean in DOS days. There was also such thread in Linux, I think it
>>>>>>> is called Cooperative multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking
>>>>>>>
>>>>>>>>> This remind me of a problem of the 'language'. Why we can't say:
>>>>>>>>>
>>>>>>>>> thread void f(Arg arg1); // 'thread' is keyword
>>>>>>>>>
>>>>>>>>> instead of lots of "weird" syntax, if we want to talk about "language"?
>>>>>>>>
>>>>>>>> C++ threading is fairly "flexible", well, imho. Wrt C11 threads its akin
>>>>>>>> to PThreads. Well, minus the fine grain control we have wrt the "newer"
>>>>>>>> standards... C++/C 11 and such. The DWCAS issue aside for a moment, its
>>>>>>>> not all that bad.
>>>>>>>>
>>>>>>>
>>>>>>> If so, use pthread to invent what you want, in stead of too many 'weird' modifications.
>>>>>>> All are confined in your source. it should be easier to manage and less work and errors.
>>>>>>>
>>>>>>
>>>>>> I used to use Pthreads all the time, and resort to asm for the lock-free
>>>>>> bits... They were for pre C/C++11 impls. The damn DWCAS issue is
>>>>>> annoying to say the least!
>>>>>
>>>>> Sound like a good reason to invent your own Thread class.
>>>>> At least, you will know every thing more concrete.
>>>>>
>>>>
>>>> Well, wrt a thread class, just be sure to avoid calling into the thread
>>>> logic before the ctor of your thread class is 100% completed. I have had
>>>> to debug some really nasty bugs that dealt with that specific scenario.
>>>> Yikes!
>>>
>>> I need examples to understand what you mean. I have not touched thread issues for many years
>>> , but hope I can help.
>>>
>>
>> iirc, it was a base class that called its pure virtual thread entry
>> function _before_ its derived class had a chance to fully complete its
>> ctor. It's been a while since I have encountered this nasty scenario.
>> Thank god.
>
> class BaseThread {
> public:
> BaseThread(Func func);
> virtual ~BaseThread();
> };
>
> class Thread : BaseThread {
> public:
> Thread(Func func) {
> // init vars.
> ::pthread_create(...func...); // the last line
> };
> // ....
> }
You just have to make sure that the thread is created after class Thread
is ready for it. I have had to debug horror shows with threads created
in ctors before...
> The thread should be started in Thread (not in BaseThread), if I guess what you mean correctly.
Basically, the general rule is that a thread should be started _after_
everything it needs to use has been fully initialized.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-09 16:23 +0000 |
| Message-ID | <q0MXO.520657$FzW1.386575@fx14.iad> |
| In reply to | #120869 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 11/8/2024 4:19 PM, wij wrote:
>> class BaseThread {
>> public:
>> BaseThread(Func func);
>> virtual ~BaseThread();
>> };
>>
>> class Thread : BaseThread {
>> public:
>> Thread(Func func) {
>> // init vars.
>> ::pthread_create(...func...); // the last line
>> };
>> // ....
>> }
>
>You just have to make sure that the thread is created after class Thread
>is ready for it. I have had to debug horror shows with threads created
>in ctors before...
It's really very simple. Use a two-phase approach. The run thread
is created and immediately waits on a condition variable. When the
most derived constructor completes initialization, it signals the
condition variable before running the virtual 'run' function.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-09 12:42 -0800 |
| Message-ID | <vgohgh$3v1o1$2@dont-email.me> |
| In reply to | #120874 |
On 11/9/2024 8:23 AM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 11/8/2024 4:19 PM, wij wrote:
>
>>> class BaseThread {
>>> public:
>>> BaseThread(Func func);
>>> virtual ~BaseThread();
>>> };
>>>
>>> class Thread : BaseThread {
>>> public:
>>> Thread(Func func) {
>>> // init vars.
>>> ::pthread_create(...func...); // the last line
>>> };
>>> // ....
>>> }
>>
>> You just have to make sure that the thread is created after class Thread
>> is ready for it. I have had to debug horror shows with threads created
>> in ctors before...
>
> It's really very simple. Use a two-phase approach. The run thread
> is created and immediately waits on a condition variable. When the
> most derived constructor completes initialization, it signals the
> condition variable before running the virtual 'run' function.
>
>
Humm... Why not just make sure everything a thread needs is fully
constructed before you "launch" it? No condvars, mutexes necessary. This
is only on thread creation.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-09 23:23 +0000 |
| Message-ID | <U9SXO.278129$WtV9.208651@fx10.iad> |
| In reply to | #120876 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 11/9/2024 8:23 AM, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/8/2024 4:19 PM, wij wrote:
>>
>>>> class BaseThread {
>>>> public:
>>>> BaseThread(Func func);
>>>> virtual ~BaseThread();
>>>> };
>>>>
>>>> class Thread : BaseThread {
>>>> public:
>>>> Thread(Func func) {
>>>> // init vars.
>>>> ::pthread_create(...func...); // the last line
>>>> };
>>>> // ....
>>>> }
>>>
>>> You just have to make sure that the thread is created after class Thread
>>> is ready for it. I have had to debug horror shows with threads created
>>> in ctors before...
>>
>> It's really very simple. Use a two-phase approach. The run thread
>> is created and immediately waits on a condition variable. When the
>> most derived constructor completes initialization, it signals the
>> condition variable before running the virtual 'run' function.
>>
>>
>
>Humm... Why not just make sure everything a thread needs is fully
>constructed before you "launch" it? No condvars, mutexes necessary. This
>is only on thread creation.
The idea is that your class inherits from the thread class ahead of
any other classes which encapsulates the thread creation in the
thread class constructor, which is the natural place to look for
it.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-11-10 11:00 +0200 |
| Message-ID | <vgpsnf$aaac$1@dont-email.me> |
| In reply to | #120879 |
On 10.11.2024 01:23, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 11/9/2024 8:23 AM, Scott Lurndal wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 11/8/2024 4:19 PM, wij wrote:
>>>
>>>>> class BaseThread {
>>>>> public:
>>>>> BaseThread(Func func);
>>>>> virtual ~BaseThread();
>>>>> };
>>>>>
>>>>> class Thread : BaseThread {
>>>>> public:
>>>>> Thread(Func func) {
>>>>> // init vars.
>>>>> ::pthread_create(...func...); // the last line
>>>>> };
>>>>> // ....
>>>>> }
>>>>
>>>> You just have to make sure that the thread is created after class Thread
>>>> is ready for it. I have had to debug horror shows with threads created
>>>> in ctors before...
>>>
>>> It's really very simple. Use a two-phase approach. The run thread
>>> is created and immediately waits on a condition variable. When the
>>> most derived constructor completes initialization, it signals the
>>> condition variable before running the virtual 'run' function.
>>>
>>>
>>
>> Humm... Why not just make sure everything a thread needs is fully
>> constructed before you "launch" it? No condvars, mutexes necessary. This
>> is only on thread creation.
>
> The idea is that your class inherits from the thread class ahead of
> any other classes which encapsulates the thread creation in the
> thread class constructor, which is the natural place to look for
> it.
This would require a delayed startup as you describe earlier, which
makes things more complicated and cumbersome. I have adopted another way:
1. Never derive from std::thread.
2. If std::thread is a class member, it must be the last member.
3. Start it up by passing a lambda which calls the thread function
with needed parameters explicitly, no need to design a virtual Run()
function with a fixed rigid signature.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-12 16:56 -0800 |
| Message-ID | <vh0tf9$1rohh$2@dont-email.me> |
| In reply to | #120880 |
On 11/10/2024 1:00 AM, Paavo Helde wrote:
> On 10.11.2024 01:23, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/9/2024 8:23 AM, Scott Lurndal wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> On 11/8/2024 4:19 PM, wij wrote:
>>>>
>>>>>> class BaseThread {
>>>>>> public:
>>>>>> BaseThread(Func func);
>>>>>> virtual ~BaseThread();
>>>>>> };
>>>>>>
>>>>>> class Thread : BaseThread {
>>>>>> public:
>>>>>> Thread(Func func) {
>>>>>> // init vars.
>>>>>> ::pthread_create(...func...); // the last line
>>>>>> };
>>>>>> // ....
>>>>>> }
>>>>>
>>>>> You just have to make sure that the thread is created after class
>>>>> Thread
>>>>> is ready for it. I have had to debug horror shows with threads created
>>>>> in ctors before...
>>>>
>>>> It's really very simple. Use a two-phase approach. The run thread
>>>> is created and immediately waits on a condition variable. When the
>>>> most derived constructor completes initialization, it signals the
>>>> condition variable before running the virtual 'run' function.
>>>>
>>>
>>> Humm... Why not just make sure everything a thread needs is fully
>>> constructed before you "launch" it? No condvars, mutexes necessary. This
>>> is only on thread creation.
>>
>> The idea is that your class inherits from the thread class ahead of
>> any other classes which encapsulates the thread creation in the
>> thread class constructor, which is the natural place to look for
>> it.
>
> This would require a delayed startup as you describe earlier, which
> makes things more complicated and cumbersome. I have adopted another way:
>
> 1. Never derive from std::thread.
>
> 2. If std::thread is a class member, it must be the last member.
>
> 3. Start it up by passing a lambda which calls the thread function
> with needed parameters explicitly, no need to design a virtual Run()
> function with a fixed rigid signature.
>
Ditto! Hyper similar thought crossed my mind as well Paavo. Strange! ;^o
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-12 16:59 -0800 |
| Message-ID | <vh0tm4$1rohh$3@dont-email.me> |
| In reply to | #120889 |
On 11/12/2024 4:56 PM, Chris M. Thomasson wrote:
> On 11/10/2024 1:00 AM, Paavo Helde wrote:
>> On 10.11.2024 01:23, Scott Lurndal wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 11/9/2024 8:23 AM, Scott Lurndal wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>> On 11/8/2024 4:19 PM, wij wrote:
>>>>>
>>>>>>> class BaseThread {
>>>>>>> public:
>>>>>>> BaseThread(Func func);
>>>>>>> virtual ~BaseThread();
>>>>>>> };
>>>>>>>
>>>>>>> class Thread : BaseThread {
>>>>>>> public:
>>>>>>> Thread(Func func) {
>>>>>>> // init vars.
>>>>>>> ::pthread_create(...func...); // the last line
>>>>>>> };
>>>>>>> // ....
>>>>>>> }
>>>>>>
>>>>>> You just have to make sure that the thread is created after class
>>>>>> Thread
>>>>>> is ready for it. I have had to debug horror shows with threads
>>>>>> created
>>>>>> in ctors before...
>>>>>
>>>>> It's really very simple. Use a two-phase approach. The run thread
>>>>> is created and immediately waits on a condition variable. When the
>>>>> most derived constructor completes initialization, it signals the
>>>>> condition variable before running the virtual 'run' function.
>>>>>
>>>>
>>>> Humm... Why not just make sure everything a thread needs is fully
>>>> constructed before you "launch" it? No condvars, mutexes necessary.
>>>> This
>>>> is only on thread creation.
>>>
>>> The idea is that your class inherits from the thread class ahead of
>>> any other classes which encapsulates the thread creation in the
>>> thread class constructor, which is the natural place to look for
>>> it.
>>
>> This would require a delayed startup as you describe earlier, which
>> makes things more complicated and cumbersome. I have adopted another way:
>>
>> 1. Never derive from std::thread.
>>
>> 2. If std::thread is a class member, it must be the last member.
>>
>> 3. Start it up by passing a lambda which calls the thread function
>> with needed parameters explicitly, no need to design a virtual Run()
>> function with a fixed rigid signature.
>>
>
> Ditto! Hyper similar thought crossed my mind as well Paavo. Strange! ;^o
Say a thread needs to use a "local _but_ global" queue and a stack.
Well, those (the queue and stack) better be constructed and ready to
roll, before any damn thread can access them at all! Just, well, imvho
that is. ;^o
I say local but global wrt some of my example code that puts the shared
data in the main thread.
Any Thoughts on this matter? Shit.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-12 17:05 -0800 |
| Message-ID | <vh0u1b$1rohh$5@dont-email.me> |
| In reply to | #120890 |
On 11/12/2024 4:59 PM, Chris M. Thomasson wrote:
> On 11/12/2024 4:56 PM, Chris M. Thomasson wrote:
>> On 11/10/2024 1:00 AM, Paavo Helde wrote:
>>> On 10.11.2024 01:23, Scott Lurndal wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> On 11/9/2024 8:23 AM, Scott Lurndal wrote:
>>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>>> On 11/8/2024 4:19 PM, wij wrote:
>>>>>>
>>>>>>>> class BaseThread {
>>>>>>>> public:
>>>>>>>> BaseThread(Func func);
>>>>>>>> virtual ~BaseThread();
>>>>>>>> };
>>>>>>>>
>>>>>>>> class Thread : BaseThread {
>>>>>>>> public:
>>>>>>>> Thread(Func func) {
>>>>>>>> // init vars.
>>>>>>>> ::pthread_create(...func...); // the last line
>>>>>>>> };
>>>>>>>> // ....
>>>>>>>> }
>>>>>>>
>>>>>>> You just have to make sure that the thread is created after class
>>>>>>> Thread
>>>>>>> is ready for it. I have had to debug horror shows with threads
>>>>>>> created
>>>>>>> in ctors before...
>>>>>>
>>>>>> It's really very simple. Use a two-phase approach. The run thread
>>>>>> is created and immediately waits on a condition variable. When the
>>>>>> most derived constructor completes initialization, it signals the
>>>>>> condition variable before running the virtual 'run' function.
>>>>>>
>>>>>
>>>>> Humm... Why not just make sure everything a thread needs is fully
>>>>> constructed before you "launch" it? No condvars, mutexes necessary.
>>>>> This
>>>>> is only on thread creation.
>>>>
>>>> The idea is that your class inherits from the thread class ahead of
>>>> any other classes which encapsulates the thread creation in the
>>>> thread class constructor, which is the natural place to look for
>>>> it.
>>>
>>> This would require a delayed startup as you describe earlier, which
>>> makes things more complicated and cumbersome. I have adopted another
>>> way:
>>>
>>> 1. Never derive from std::thread.
>>>
>>> 2. If std::thread is a class member, it must be the last member.
>>>
>>> 3. Start it up by passing a lambda which calls the thread
>>> function with needed parameters explicitly, no need to design a
>>> virtual Run() function with a fixed rigid signature.
>>>
>>
>> Ditto! Hyper similar thought crossed my mind as well Paavo. Strange! ;^o
>
> Say a thread needs to use a "local _but_ global" queue and a stack.
> Well, those (the queue and stack) better be constructed and ready to
> roll, before any damn thread can access them at all! Just, well, imvho
> that is. ;^o
>
> I say local but global wrt some of my example code that puts the shared
> data in the main thread.
>
> Any Thoughts on this matter? Shit.
local but global? lol! What do you think. shared is global in an odd
sense. But its contained in mains local context, so to speak? Weasel
words, or kind of okay?
_____________
int
main()
{
std::cout << "ct_proxy_collector testing 123...\n";
std::cout << "_________________________________\n\n" << std::endl;
{
ct_shared shared;
{
std::thread threads[CT_THREAD_N];
std::cout << "Launching threads and processing...\n";
std::cout << "____________________\n" << std::endl;
{
{
// Create worker threads...
for (unsigned long i = 0; i < CT_THREAD_WORKERS_N; ++i)
{
threads[i] = std::thread(ct_worker_thread,
std::ref(shared), i);
}
_____________
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-11-09 12:01 +0000 |
| Message-ID | <vgniu2$3p4s2$1@dont-email.me> |
| In reply to | #120865 |
On Fri, 8 Nov 2024 15:40:49 -0800 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >On 11/8/2024 3:13 PM, wij wrote: >> I need examples to understand what you mean. I have not touched thread >issues for many years >> , but hope I can help. >> > >iirc, it was a base class that called its pure virtual thread entry >function _before_ its derived class had a chance to fully complete its >ctor. It's been a while since I have encountered this nasty scenario. Its such an old and well known C++ problem it often comes up in interview questions.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web