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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-11-09 12:01 +0000 |
| Message-ID | <vgniu6$3p4t6$1@dont-email.me> |
| In reply to | #120847 |
On Fri, 8 Nov 2024 12:40:36 -0800 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>> https://en.wikipedia.org/wiki/ABA_problem >> >> Why's it a problem? Its why mutexes exist. > >What if one did not want to use a mutex? Then put up with the faff of semaphores or atomics and risk creating some edge case race conditions. If you're worried about threads getting blocked too often then you haven't designed your program correctly.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-09 12:39 -0800 |
| Message-ID | <vgoh9n$3v1o1$1@dont-email.me> |
| In reply to | #120872 |
On 11/9/2024 4:01 AM, Muttley@dastardlyhq.com wrote: > On Fri, 8 Nov 2024 12:40:36 -0800 > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>> https://en.wikipedia.org/wiki/ABA_problem >>> >>> Why's it a problem? Its why mutexes exist. >> >> What if one did not want to use a mutex? > > Then put up with the faff of semaphores or atomics and risk creating some > edge case race conditions. Using lock/wait/obstruction-free algorithms is not about creating race conditions... :^) > If you're worried about threads getting blocked > too often then you haven't designed your program correctly. Not sure what you mean here... It's all about minimizing slow-paths, and maximizing fast-paths. :^)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-11-11 09:56 +0000 |
| Message-ID | <vgskbm$u59u$1@dont-email.me> |
| In reply to | #120875 |
On Sat, 9 Nov 2024 12:39:19 -0800 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >On 11/9/2024 4:01 AM, Muttley@dastardlyhq.com wrote: >> On Fri, 8 Nov 2024 12:40:36 -0800 >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>> https://en.wikipedia.org/wiki/ABA_problem >>>> >>>> Why's it a problem? Its why mutexes exist. >>> >>> What if one did not want to use a mutex? >> >> Then put up with the faff of semaphores or atomics and risk creating some >> edge case race conditions. > >Using lock/wait/obstruction-free algorithms is not about creating race >conditions... :^) 3 level locking generally solves most problems IME. C++ didn't have until 2017 when shared_mutex came along even though pthreads has had it forever and was a reason people kept using pthreads in C++. >Not sure what you mean here... It's all about minimizing slow-paths, and >maximizing fast-paths. :^) Fast paths are no use if the thread doesn't have anything else to do anyway.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-11 13:36 -0800 |
| Message-ID | <vgttdl$16bjf$1@dont-email.me> |
| In reply to | #120883 |
On 11/11/2024 1:56 AM, Muttley@DastartdlyHQ.org wrote: > On Sat, 9 Nov 2024 12:39:19 -0800 > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >> On 11/9/2024 4:01 AM, Muttley@dastardlyhq.com wrote: >>> On Fri, 8 Nov 2024 12:40:36 -0800 >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>> >>>>> Why's it a problem? Its why mutexes exist. >>>> >>>> What if one did not want to use a mutex? >>> >>> Then put up with the faff of semaphores or atomics and risk creating some >>> edge case race conditions. >> >> Using lock/wait/obstruction-free algorithms is not about creating race >> conditions... :^) > > 3 level locking generally solves most problems IME. C++ didn't have until 2017 > when shared_mutex came along even though pthreads has had it forever and was > a reason people kept using pthreads in C++. Not sure what you mean by 3 level locking. Are you talking about PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty conditions that used recursive locks. Ouch. >> Not sure what you mean here... It's all about minimizing slow-paths, and >> maximizing fast-paths. :^) > > Fast paths are no use if the thread doesn't have anything else to do anyway. > If a thread has nothing to do, it can wait, for something to do. ;^) Think of an empty queue condition. A thread can just wait on it...
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-11-12 08:28 +0000 |
| Message-ID | <vgv3jb$1gkjr$1@dont-email.me> |
| In reply to | #120884 |
On Mon, 11 Nov 2024 13:36:53 -0800 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >On 11/11/2024 1:56 AM, Muttley@DastartdlyHQ.org wrote: >> On Sat, 9 Nov 2024 12:39:19 -0800 >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >>> On 11/9/2024 4:01 AM, Muttley@dastardlyhq.com wrote: >>>> On Fri, 8 Nov 2024 12:40:36 -0800 >>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>> >>>>>> Why's it a problem? Its why mutexes exist. >>>>> >>>>> What if one did not want to use a mutex? >>>> >>>> Then put up with the faff of semaphores or atomics and risk creating some >>>> edge case race conditions. >>> >>> Using lock/wait/obstruction-free algorithms is not about creating race >>> conditions... :^) >> >> 3 level locking generally solves most problems IME. C++ didn't have until >2017 >> when shared_mutex came along even though pthreads has had it forever and was >> a reason people kept using pthreads in C++. > >Not sure what you mean by 3 level locking. Are you talking about Seriously? >PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty >conditions that used recursive locks. Ouch. No, I'm talking about read locks vs read-write locks. >> Fast paths are no use if the thread doesn't have anything else to do anyway. >> > >If a thread has nothing to do, it can wait, for something to do. ;^) > >Think of an empty queue condition. A thread can just wait on it... Sure, but then who needs a "fast path"? Just sit on the mutex/condition variable.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-12 13:56 -0800 |
| Message-ID | <vh0iuu$1q1hl$1@dont-email.me> |
| In reply to | #120885 |
On 11/12/2024 12:28 AM, Muttley@DastartdlyHQ.org wrote: > On Mon, 11 Nov 2024 13:36:53 -0800 > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >> On 11/11/2024 1:56 AM, Muttley@DastartdlyHQ.org wrote: >>> On Sat, 9 Nov 2024 12:39:19 -0800 >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >>>> On 11/9/2024 4:01 AM, Muttley@dastardlyhq.com wrote: >>>>> On Fri, 8 Nov 2024 12:40:36 -0800 >>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>>> >>>>>>> Why's it a problem? Its why mutexes exist. >>>>>> >>>>>> What if one did not want to use a mutex? >>>>> >>>>> Then put up with the faff of semaphores or atomics and risk creating some >>>>> edge case race conditions. >>>> >>>> Using lock/wait/obstruction-free algorithms is not about creating race >>>> conditions... :^) >>> >>> 3 level locking generally solves most problems IME. C++ didn't have until >> 2017 >>> when shared_mutex came along even though pthreads has had it forever and was >>> a reason people kept using pthreads in C++. >> >> Not sure what you mean by 3 level locking. Are you talking about > > Seriously? > >> PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty >> conditions that used recursive locks. Ouch. > > No, I'm talking about read locks vs read-write locks. > >>> Fast paths are no use if the thread doesn't have anything else to do anyway. >>> >> >> If a thread has nothing to do, it can wait, for something to do. ;^) >> >> Think of an empty queue condition. A thread can just wait on it... > > Sure, but then who needs a "fast path"? Just sit on the mutex/condition > variable. > lock/wait free fast-paths really shine when the system is under _load_. They allow for damn good scalability. A mutex has a lot of trouble scaling. Even distributed mutexes cannot scale as good.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-12 13:59 -0800 |
| Message-ID | <vh0j3m$1q1hl$2@dont-email.me> |
| In reply to | #120886 |
On 11/12/2024 1:56 PM, Chris M. Thomasson wrote: > On 11/12/2024 12:28 AM, Muttley@DastartdlyHQ.org wrote: >> On Mon, 11 Nov 2024 13:36:53 -0800 >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >>> On 11/11/2024 1:56 AM, Muttley@DastartdlyHQ.org wrote: >>>> On Sat, 9 Nov 2024 12:39:19 -0800 >>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >>>>> On 11/9/2024 4:01 AM, Muttley@dastardlyhq.com wrote: >>>>>> On Fri, 8 Nov 2024 12:40:36 -0800 >>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >>>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>>>> >>>>>>>> Why's it a problem? Its why mutexes exist. >>>>>>> >>>>>>> What if one did not want to use a mutex? >>>>>> >>>>>> Then put up with the faff of semaphores or atomics and risk >>>>>> creating some >>>>>> edge case race conditions. >>>>> >>>>> Using lock/wait/obstruction-free algorithms is not about creating race >>>>> conditions... :^) >>>> >>>> 3 level locking generally solves most problems IME. C++ didn't have >>>> until >>> 2017 >>>> when shared_mutex came along even though pthreads has had it forever >>>> and was >>>> a reason people kept using pthreads in C++. >>> >>> Not sure what you mean by 3 level locking. Are you talking about >> >> Seriously? >> >>> PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty >>> conditions that used recursive locks. Ouch. >> >> No, I'm talking about read locks vs read-write locks. >> >>>> Fast paths are no use if the thread doesn't have anything else to do >>>> anyway. >>>> >>> >>> If a thread has nothing to do, it can wait, for something to do. ;^) >>> >>> Think of an empty queue condition. A thread can just wait on it... >> >> Sure, but then who needs a "fast path"? Just sit on the mutex/condition >> variable. >> > > lock/wait free fast-paths really shine when the system is under _load_. > They allow for damn good scalability. A mutex has a lot of trouble > scaling. Even distributed mutexes cannot scale as good. Think of comparing a mutex based solution vs something like, RCU. The performance is not even barely close.
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-11-12 16:20 -0800 |
| Message-ID | <u0mdnR4KYrxnba76nZ2dnZfqnPidnZ2d@giganews.com> |
| In reply to | #120886 |
On 11/12/2024 01:56 PM, Chris M. Thomasson wrote: > On 11/12/2024 12:28 AM, Muttley@DastartdlyHQ.org wrote: >> On Mon, 11 Nov 2024 13:36:53 -0800 >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >>> On 11/11/2024 1:56 AM, Muttley@DastartdlyHQ.org wrote: >>>> On Sat, 9 Nov 2024 12:39:19 -0800 >>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> boring babbled: >>>>> On 11/9/2024 4:01 AM, Muttley@dastardlyhq.com wrote: >>>>>> On Fri, 8 Nov 2024 12:40:36 -0800 >>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >>>>>>> On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote: >>>>>>>>> https://en.wikipedia.org/wiki/ABA_problem >>>>>>>> >>>>>>>> Why's it a problem? Its why mutexes exist. >>>>>>> >>>>>>> What if one did not want to use a mutex? >>>>>> >>>>>> Then put up with the faff of semaphores or atomics and risk >>>>>> creating some >>>>>> edge case race conditions. >>>>> >>>>> Using lock/wait/obstruction-free algorithms is not about creating race >>>>> conditions... :^) >>>> >>>> 3 level locking generally solves most problems IME. C++ didn't have >>>> until >>> 2017 >>>> when shared_mutex came along even though pthreads has had it forever >>>> and was >>>> a reason people kept using pthreads in C++. >>> >>> Not sure what you mean by 3 level locking. Are you talking about >> >> Seriously? >> >>> PTHREAD_MUTEX_RECURSIVE? ohhh. I have had to debug some very nasty >>> conditions that used recursive locks. Ouch. >> >> No, I'm talking about read locks vs read-write locks. >> >>>> Fast paths are no use if the thread doesn't have anything else to do >>>> anyway. >>>> >>> >>> If a thread has nothing to do, it can wait, for something to do. ;^) >>> >>> Think of an empty queue condition. A thread can just wait on it... >> >> Sure, but then who needs a "fast path"? Just sit on the mutex/condition >> variable. >> > > lock/wait free fast-paths really shine when the system is under _load_. > They allow for damn good scalability. A mutex has a lot of trouble > scaling. Even distributed mutexes cannot scale as good. Well, there's design for correctness, and Murphy's law, and hope for the best, and Murphy's law. A usual notion of "non-blocking co-operatively" makes for a usual notion of "incremental progress". Which is usually implemented as pre-emptive multi-threading, .... Where round-robin is usually considered fair, .... It's like an idea about a digital signal processor, and the systolic and constant-rate, and the idea that anything that backs up needs a buffer, on the chip, vis-a-vis, keeping the DMA bus hot, versus keeping it not. Guy was like "I overclocked a simple routine, now all you need to do is add a huge burst-buffer", and it's like, "well then you won't mind it coming out of your budget". Or like "just add a huge cache, don't worry that anybody will mess with it". The branch-free paths really shine under load, .... There is contention for resources, ..., yet the over-allocation is a usual failure mode of the budgetary analysis. "What's the best performing routine on that system?" "I don't know, it just says 'idle'."
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-11-10 13:02 -0800 |
| Message-ID | <tfCdnVOi-NHRgqz6nZ2dnZfqn_YAAAAA@giganews.com> |
| In reply to | #120847 |
On 11/08/2024 12:40 PM, 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. > > What if one did not want to use a mutex? > > >> Why would anyone expect non >> synchronised RW memory access to work? The exact same problem occurs >> in databases with dirty reads. >> > Usually called serialization or "the monad", .... The database as a critical transactional resource via serialization is sort of exactly a sort of memory barrier with regards to defined behavior that reduced pretty much to compare-and-swap, then incrementing a counter in that as a tuple. I.e., when compare-and-swap is the only atomic operation.
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-11-10 13:05 -0800 |
| Message-ID | <tfCdnVKi-NFugqz6nZ2dnZfqn_adnZ2d@giganews.com> |
| In reply to | #120881 |
On 11/10/2024 01:02 PM, Ross Finlayson wrote: > On 11/08/2024 12:40 PM, 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. >> >> What if one did not want to use a mutex? >> >> >>> Why would anyone expect non >>> synchronised RW memory access to work? The exact same problem occurs >>> in databases with dirty reads. >>> >> > > Usually called serialization or "the monad", .... > > The database as a critical transactional resource > via serialization is sort of exactly a sort of > memory barrier with regards to defined behavior > that reduced pretty much to compare-and-swap, > then incrementing a counter in that as a tuple. > > I.e., when compare-and-swap is the only atomic operation. > > It's sort of up to the OS according to the architecture, that critical resources are smaller. Correctness of course is usually considered paramount, with regards to something like buffers as queues, and atomic swap on the tail, for a most usual sort of algorithm the "slique" or "mono-hydra", with regards to read-twice consume-once, what results then non-blocking, and re-entrant.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 12:46 -0800 |
| Message-ID | <vgltbu$3bm14$1@dont-email.me> |
| In reply to | #120846 |
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?
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 05:18 +0800 |
| Message-ID | <47b2fbcfd0d7f49d6e7ebe51089bee646ee5ab29.camel@gmail.com> |
| In reply to | #120848 |
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?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 13:23 -0800 |
| Message-ID | <vglvgv$3c2t2$1@dont-email.me> |
| In reply to | #120849 |
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? > Well, C++11 allows us to create lock-free algorithms using pure standard C++. The DWCAS issue aside for a moment. Well, it's on topic wrt C++ itself? Standard atomics and memory barriers... Compiler barriers to boot via atomic_signal_fence: https://en.cppreference.com/w/cpp/atomic/atomic_signal_fence I still don't know why its so hard to apply lock-free DWCAS to the std. Well, wrt always lock-free using C++'s own terms... https://en.cppreference.com/w/cpp/atomic/atomic/is_always_lock_free ;^) I love C++'s "sometimes" lock-free wording... Oh wow.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 05:25 +0800 |
| Message-ID | <fda5cdb67b10c91459590cab332e998b4c5e3590.camel@gmail.com> |
| In reply to | #120849 |
On Sat, 2024-11-09 at 05:18 +0800, 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? > Typo: why not just turning off multi-tasking?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 13:27 -0800 |
| Message-ID | <vglvnv$3c2t2$2@dont-email.me> |
| In reply to | #120849 |
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?
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 06:02 +0800 |
| Message-ID | <da09f7379bfc1675ebedbc471af3e6467739640a.camel@gmail.com> |
| In reply to | #120852 |
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. 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"?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 14:09 -0800 |
| Message-ID | <vgm26b$3cdkg$1@dont-email.me> |
| In reply to | #120853 |
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. > 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.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 06:35 +0800 |
| Message-ID | <48b27c2bb42d6ae1c4fcd6dba2d4102ca2c19bfa.camel@gmail.com> |
| In reply to | #120854 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-08 14:37 -0800 |
| Message-ID | <vgm3qh$3cunt$1@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. > pthreads does not provide standard membars and atomics... C/C++11 does.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-09 06:47 +0800 |
| Message-ID | <774ef9f5e21d99eb91bf912161124670576d722e.camel@gmail.com> |
| In reply to | #120856 |
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).
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web