Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #122453 > unrolled thread
| Started by | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| First post | 2025-07-29 22:54 -0700 |
| Last post | 2025-08-07 21:08 -0700 |
| Articles | 20 on this page of 90 — 6 participants |
Back to article view | Back to comp.lang.c++
fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-07-29 22:54 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-02 12:58 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-02 13:00 -0700
Re: fun with a mutex... Muttley@DastardlyHQ.org - 2025-08-04 08:48 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-04 12:34 -0700
Re: fun with a mutex... Muttley@DastardlyHQ.org - 2025-08-05 07:27 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-05 16:10 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-06 00:38 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-05 19:14 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-06 11:29 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-06 15:43 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-08 01:41 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-07 20:52 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-05 19:16 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-06 12:04 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-06 15:47 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-08 01:49 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-07 20:59 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-09 09:17 +0000
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-09 11:52 +0200
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-09 16:08 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-09 10:48 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-10 03:08 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-11 13:37 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 11:41 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-15 17:28 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-18 20:25 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 13:34 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-18 20:39 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 14:06 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 14:28 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 14:33 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-18 22:56 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 16:09 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-18 23:44 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 16:55 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-18 23:57 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-19 13:25 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-15 17:30 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-18 20:26 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 13:39 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-18 20:44 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 14:08 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 16:11 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 16:20 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-11 11:04 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-11 13:30 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-12 10:23 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-12 01:31 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-12 10:39 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-12 01:45 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-12 10:56 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-12 02:14 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-12 15:08 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-15 21:36 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-16 10:13 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-16 01:56 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-16 11:05 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-16 13:31 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-17 14:50 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-17 13:43 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 11:45 +0000
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-13 19:07 +0200
Re: fun with a mutex... scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 17:31 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-15 10:00 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-13 12:41 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-09 10:44 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-09 11:00 -0700
Re: fun with a mutex... "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-08-05 10:27 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-05 16:07 -0700
Re: fun with a mutex... "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-08-06 10:56 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-06 15:36 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-04 12:38 -0700
Re: fun with a mutex... Muttley@DastardlyHQ.org - 2025-08-05 07:29 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-05 16:08 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-06 15:51 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-06 15:34 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-07 06:44 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-07 12:17 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-07 21:51 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-07 12:52 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-16 11:21 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-16 13:22 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-17 03:59 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-16 23:53 -0700
Re: fun with a mutex... Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-17 10:37 +0200
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-07 12:32 -0700
Re: fun with a mutex... cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-08 01:51 +0000
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-07 21:01 -0700
Re: fun with a mutex... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-07 21:08 -0700
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-09 16:08 +0000 |
| Message-ID | <1077rpr$sk$1@reader1.panix.com> |
| In reply to | #122501 |
In article <10775om$17ms4$1@raubtier-asyl.eternal-september.org>, Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 09.08.2025 um 11:17 schrieb Dan Cross: > >> People have written code that tries to take a lock, and if that >> fails, does something else, for decades. The idea is neither >> new, nor terribly interesting. Sorry. > >I think this pattern is extremely rare because the task that needs to >be done elsewhere must be able to be omitted completely if necessary, >and if not, it must be short enough that it doesn't interfere with >waiting for the mutex. Yeah. That's why I mentioned concentrating on the specific critical section the mutex is protecting, not the locking protocol. Where this has any utility at all, it's in places where the "something else" is well-known, which implies it being a function of the critsec. It's going to be things like, "if I fail to acquire the scheduler lock, then increment this per-core atomic counter that's measuring contention...." sort of thing. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-09 10:48 -0700 |
| Message-ID | <10781l0$1eamj$2@dont-email.me> |
| In reply to | #122502 |
On 8/9/2025 9:08 AM, Dan Cross wrote: > In article <10775om$17ms4$1@raubtier-asyl.eternal-september.org>, > Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 09.08.2025 um 11:17 schrieb Dan Cross: >> >>> People have written code that tries to take a lock, and if that >>> fails, does something else, for decades. The idea is neither >>> new, nor terribly interesting. Sorry. >> >> I think this pattern is extremely rare because the task that needs to >> be done elsewhere must be able to be omitted completely if necessary, >> and if not, it must be short enough that it doesn't interfere with >> waiting for the mutex. > > Yeah. That's why I mentioned concentrating on the specific > critical section the mutex is protecting, not the locking > protocol. Where this has any utility at all, it's in places > where the "something else" is well-known, which implies it being > a function of the critsec. It's going to be things like, "if I > fail to acquire the scheduler lock, then increment this per-core > atomic counter that's measuring contention...." sort of thing. More grasping at straws and/or trying to breath underwater without scuba gear... The other work is very specialized. It can be as simple as processing a per-thread local queue or something. Just something that can act like a backoff that does real work in a case of contention. Sigh.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-10 03:08 +0000 |
| Message-ID | <10792fs$ffk$1@reader1.panix.com> |
| In reply to | #122504 |
In article <10781l0$1eamj$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/9/2025 9:08 AM, Dan Cross wrote: >> In article <10775om$17ms4$1@raubtier-asyl.eternal-september.org>, >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 09.08.2025 um 11:17 schrieb Dan Cross: >>> >>>> People have written code that tries to take a lock, and if that >>>> fails, does something else, for decades. The idea is neither >>>> new, nor terribly interesting. Sorry. >>> >>> I think this pattern is extremely rare because the task that needs to >>> be done elsewhere must be able to be omitted completely if necessary, >>> and if not, it must be short enough that it doesn't interfere with >>> waiting for the mutex. >> >> Yeah. That's why I mentioned concentrating on the specific >> critical section the mutex is protecting, not the locking >> protocol. Where this has any utility at all, it's in places >> where the "something else" is well-known, which implies it being >> a function of the critsec. It's going to be things like, "if I >> fail to acquire the scheduler lock, then increment this per-core >> atomic counter that's measuring contention...." sort of thing. > >More grasping at straws and/or trying to breath underwater without scuba >gear... The other work is very specialized. It can be as simple as >processing a per-thread local queue or something. Just something that >can act like a backoff that does real work in a case of contention. Sigh. That's the sort of thing where you cannot know what's on that "per-thread local queue" that makes your scheme fail. If your lock is contended, you could just sleep on it, and let the kernel schedule something else instead. There's no value to keeping your thread "hot" unless you've got a profile showing that it's an issue. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-11 13:37 -0700 |
| Message-ID | <107dkai$2rg26$2@dont-email.me> |
| In reply to | #122506 |
On 8/9/2025 8:08 PM, Dan Cross wrote: > In article <10781l0$1eamj$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/9/2025 9:08 AM, Dan Cross wrote: >>> In article <10775om$17ms4$1@raubtier-asyl.eternal-september.org>, >>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Am 09.08.2025 um 11:17 schrieb Dan Cross: >>>> >>>>> People have written code that tries to take a lock, and if that >>>>> fails, does something else, for decades. The idea is neither >>>>> new, nor terribly interesting. Sorry. >>>> >>>> I think this pattern is extremely rare because the task that needs to >>>> be done elsewhere must be able to be omitted completely if necessary, >>>> and if not, it must be short enough that it doesn't interfere with >>>> waiting for the mutex. >>> >>> Yeah. That's why I mentioned concentrating on the specific >>> critical section the mutex is protecting, not the locking >>> protocol. Where this has any utility at all, it's in places >>> where the "something else" is well-known, which implies it being >>> a function of the critsec. It's going to be things like, "if I >>> fail to acquire the scheduler lock, then increment this per-core >>> atomic counter that's measuring contention...." sort of thing. >> >> More grasping at straws and/or trying to breath underwater without scuba >> gear... The other work is very specialized. It can be as simple as >> processing a per-thread local queue or something. Just something that >> can act like a backoff that does real work in a case of contention. Sigh. > > That's the sort of thing where you cannot know what's on that > "per-thread local queue" that makes your scheme fail. Well, that per-thread local queue can be for organization, maintenance, sending the results to a "logic" thread, ect. Think of a server io thread that takes the io completions and organizes them into local queues. These io threads do not call into user logic, or processing wrt say, parsing HTTP, or some protocol. So, some work that can be used after a try_lock fails can be to push the local queues to the logic threads. > If your lock is contended, you could just sleep on it, and let > the kernel schedule something else instead. There's no value to > keeping your thread "hot" unless you've got a profile showing > that it's an issue. But why sleep when the thread can do some real work? Argh. Grasping again. Feels like I am drowning. Shit! ;^o
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-13 11:41 +0000 |
| Message-ID | <107htlf$bq7$1@reader1.panix.com> |
| In reply to | #122512 |
In article <107dkai$2rg26$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/9/2025 8:08 PM, Dan Cross wrote: >> In article <10781l0$1eamj$2@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 8/9/2025 9:08 AM, Dan Cross wrote: >>>> In article <10775om$17ms4$1@raubtier-asyl.eternal-september.org>, >>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>> Am 09.08.2025 um 11:17 schrieb Dan Cross: >>>>> >>>>>> People have written code that tries to take a lock, and if that >>>>>> fails, does something else, for decades. The idea is neither >>>>>> new, nor terribly interesting. Sorry. >>>>> >>>>> I think this pattern is extremely rare because the task that needs to >>>>> be done elsewhere must be able to be omitted completely if necessary, >>>>> and if not, it must be short enough that it doesn't interfere with >>>>> waiting for the mutex. >>>> >>>> Yeah. That's why I mentioned concentrating on the specific >>>> critical section the mutex is protecting, not the locking >>>> protocol. Where this has any utility at all, it's in places >>>> where the "something else" is well-known, which implies it being >>>> a function of the critsec. It's going to be things like, "if I >>>> fail to acquire the scheduler lock, then increment this per-core >>>> atomic counter that's measuring contention...." sort of thing. >>> >>> More grasping at straws and/or trying to breath underwater without scuba >>> gear... The other work is very specialized. It can be as simple as >>> processing a per-thread local queue or something. Just something that >>> can act like a backoff that does real work in a case of contention. Sigh. >> >> That's the sort of thing where you cannot know what's on that >> "per-thread local queue" that makes your scheme fail. > >Well, that per-thread local queue can be for organization, maintenance, >sending the results to a "logic" thread, ect. Think of a server io >thread that takes the io completions and organizes them into local >queues. These io threads do not call into user logic, or processing wrt >say, parsing HTTP, or some protocol. So, some work that can be used >after a try_lock fails can be to push the local queues to the logic threads. This, yet again, seems to be where you don't understand the issue at stake here. You can _probably_ find _any number of things_ that you can do while looping over `try_lock`. I don't care about the specific examples: they obviously exist. But what you _cannot_ do, and what makes this sort of scheme fail, is know that _all_ such work is safe. Unless you can wave a magic wand and solve the halting problem, you won't be able to know that some jerk won't send you "work" that amounts to a non-terminating infinite loop. You won't be able to know that some other jerk hasn't sent you "work" that causes you to deadlock trying to take a mutex you already hold. Etc. If you _ever_ open yourself up to accepting "work" on some kind of queue, where the types of all work that can possibly be sent to you is not known in advance _in some way that can be enforced in code_, then your scheme fails. And if you do have some way to enforce those constraints, then the scheme is neither novel nor particularly interesting. >> If your lock is contended, you could just sleep on it, and let >> the kernel schedule something else instead. There's no value to >> keeping your thread "hot" unless you've got a profile showing >> that it's an issue. > >But why sleep when the thread can do some real work? Because the OS (or even a user-level thread scheduler, or language runtime, or whatever) can find work to usefully do on that CPU, _without_ the downsides mentioned above. So you lose nothing but gain correctness and stability. >Argh. Grasping >again. Feels like I am drowning. Shit! ;^o Perhaps stop doing that, then. It's clear you are not going to find a way to make whatever partially developed idea you have work. It's ok to be wrong. It's less ok to keep trying to convince others that you are right. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-15 17:28 -0700 |
| Message-ID | <107ojb9$1e84t$1@dont-email.me> |
| In reply to | #122523 |
On 8/13/2025 4:41 AM, Dan Cross wrote: > In article <107dkai$2rg26$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: When you get bored, give my lock-free proxy collector a spin... https://pastebin.com/raw/CYZ78gVj
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-18 20:25 +0000 |
| Message-ID | <1080277$h40$1@reader1.panix.com> |
| In reply to | #122539 |
In article <107ojb9$1e84t$1@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/13/2025 4:41 AM, Dan Cross wrote: >> In article <107dkai$2rg26$2@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > >When you get bored, give my lock-free proxy collector a spin... >https://pastebin.com/raw/CYZ78gVj No need, I'm afraid. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 13:34 -0700 |
| Message-ID | <10802os$3bdl8$1@dont-email.me> |
| In reply to | #122564 |
On 8/18/2025 1:25 PM, Dan Cross wrote: > In article <107ojb9$1e84t$1@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/13/2025 4:41 AM, Dan Cross wrote: >>> In article <107dkai$2rg26$2@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> >> When you get bored, give my lock-free proxy collector a spin... >> https://pastebin.com/raw/CYZ78gVj > > No need, I'm afraid. You don't like proxy collectors? Or you think mine is shit?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-18 20:39 +0000 |
| Message-ID | <108032l$h40$3@reader1.panix.com> |
| In reply to | #122566 |
In article <10802os$3bdl8$1@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/18/2025 1:25 PM, Dan Cross wrote: >> In article <107ojb9$1e84t$1@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 8/13/2025 4:41 AM, Dan Cross wrote: >>>> In article <107dkai$2rg26$2@dont-email.me>, >>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> >>> When you get bored, give my lock-free proxy collector a spin... >>> https://pastebin.com/raw/CYZ78gVj >> >> No need, I'm afraid. > >You don't like proxy collectors? Or you think mine is shit? Sorry, I'm just not sure you're a useful source of code like this. It's subtle and requires a lot of in-depth understanding of very thorny issues that it doesn't strike me you have a good handle on. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 14:06 -0700 |
| Message-ID | <10804kg$3bdl8$3@dont-email.me> |
| In reply to | #122568 |
On 8/18/2025 1:39 PM, Dan Cross wrote: > In article <10802os$3bdl8$1@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/18/2025 1:25 PM, Dan Cross wrote: >>> In article <107ojb9$1e84t$1@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 8/13/2025 4:41 AM, Dan Cross wrote: >>>>> In article <107dkai$2rg26$2@dont-email.me>, >>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> >>>> When you get bored, give my lock-free proxy collector a spin... >>>> https://pastebin.com/raw/CYZ78gVj >>> >>> No need, I'm afraid. >> >> You don't like proxy collectors? Or you think mine is shit? > > Sorry, I'm just not sure you're a useful source of code like > this. It's subtle and requires a lot of in-depth understanding > of very thorny issues that it doesn't strike me you have a good > handle on. Really? Oh well, shit happens. Well, at least have you seen Joe Seighs proxy collectors based on his most excellent atomic_ptr? Been working with lock/wait free algos for decades, and Sun even gave me a SunFire T2000 server with my vZoom project. I found the winner page on the way back machine: https://web.archive.org/web/20070620081114/https://coolthreads.dev.java.net/
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 14:28 -0700 |
| Message-ID | <10805tm$3bdl8$5@dont-email.me> |
| In reply to | #122570 |
On 8/18/2025 2:06 PM, Chris M. Thomasson wrote: > On 8/18/2025 1:39 PM, Dan Cross wrote: >> In article <10802os$3bdl8$1@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 8/18/2025 1:25 PM, Dan Cross wrote: >>>> In article <107ojb9$1e84t$1@dont-email.me>, >>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> On 8/13/2025 4:41 AM, Dan Cross wrote: >>>>>> In article <107dkai$2rg26$2@dont-email.me>, >>>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> >>>>> When you get bored, give my lock-free proxy collector a spin... >>>>> https://pastebin.com/raw/CYZ78gVj >>>> >>>> No need, I'm afraid. >>> >>> You don't like proxy collectors? Or you think mine is shit? >> >> Sorry, I'm just not sure you're a useful source of code like >> this. It's subtle and requires a lot of in-depth understanding >> of very thorny issues that it doesn't strike me you have a good >> handle on. > > Really? Oh well, shit happens. Well, at least have you seen Joe Seighs > proxy collectors based on his most excellent atomic_ptr? Been working > with lock/wait free algos for decades, and Sun even gave me a SunFire > T2000 server with my vZoom project. I found the winner page on the way > back machine: > > https://web.archive.org/web/20070620081114/https:// > coolthreads.dev.java.net/ > > Fwiw, I found one of my long past older projects on the way back machine that is still referenced by my friend who created Relacy: https://web.archive.org/web/20071008213108/http://appcore.home.comcast.net/ https://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html Here is the reference: https://www.1024cores.net/home/lock-free-algorithms/links There are more, but I seemed to have forgot about them. For some reason I am having trouble getting to the old link to c.p.t, heck back when in beta: https://web.archive.org/web/20071008213108/http://groups-beta.google.com/group/comp.programming.threads/msg/423df394a0370fa6
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 14:33 -0700 |
| Message-ID | <108067e$3ccku$2@dont-email.me> |
| In reply to | #122568 |
On 8/18/2025 1:39 PM, Dan Cross wrote: > In article <10802os$3bdl8$1@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/18/2025 1:25 PM, Dan Cross wrote: >>> In article <107ojb9$1e84t$1@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 8/13/2025 4:41 AM, Dan Cross wrote: >>>>> In article <107dkai$2rg26$2@dont-email.me>, >>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> >>>> When you get bored, give my lock-free proxy collector a spin... >>>> https://pastebin.com/raw/CYZ78gVj >>> >>> No need, I'm afraid. >> >> You don't like proxy collectors? Or you think mine is shit? > > Sorry, I'm just not sure you're a useful source of code like > this. It's subtle and requires a lot of in-depth understanding > of very thorny issues that it doesn't strike me you have a good > handle on. > > - Dan C. > Fwiw, some of my math is taking notice. An example: https://paulbourke.net/fractals/multijulia/ Also, I made it into the cover of the AMS calendar. They even put my work on their webpage: https://www.ams.org/publicoutreach/math-imagery/math-imagery Notice my name?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-18 22:56 +0000 |
| Message-ID | <1080b3i$f9e$1@reader1.panix.com> |
| In reply to | #122573 |
In article <108067e$3ccku$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/18/2025 1:39 PM, Dan Cross wrote: >> In article <10802os$3bdl8$1@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 8/18/2025 1:25 PM, Dan Cross wrote: >>>> In article <107ojb9$1e84t$1@dont-email.me>, >>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> On 8/13/2025 4:41 AM, Dan Cross wrote: >>>>>> In article <107dkai$2rg26$2@dont-email.me>, >>>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> >>>>> When you get bored, give my lock-free proxy collector a spin... >>>>> https://pastebin.com/raw/CYZ78gVj >>>> >>>> No need, I'm afraid. >>> >>> You don't like proxy collectors? Or you think mine is shit? >> >> Sorry, I'm just not sure you're a useful source of code like >> this. It's subtle and requires a lot of in-depth understanding >> of very thorny issues that it doesn't strike me you have a good >> handle on. > >Fwiw, some of my math is taking notice. An example: > >https://paulbourke.net/fractals/multijulia/ > >Also, I made it into the cover of the AMS calendar. They even put my >work on their webpage: > >https://www.ams.org/publicoutreach/math-imagery/math-imagery > >Notice my name? No, I don't. Using their integrated search feature for the string, "Thomasson" only turns up a few links to an actual mathematician working on graph theory. In fact, most of the links you are posting don't seem to involve you at all. The only one that actually seems to refer to you is a short note on Vyukov's page; I have no idea why that's there. It seems rather old. Bluntly, I'm really not all that interested. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 16:09 -0700 |
| Message-ID | <1080bs0$3dqgt$3@dont-email.me> |
| In reply to | #122576 |
On 8/18/2025 3:56 PM, Dan Cross wrote: > In article <108067e$3ccku$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/18/2025 1:39 PM, Dan Cross wrote: >>> In article <10802os$3bdl8$1@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 8/18/2025 1:25 PM, Dan Cross wrote: >>>>> In article <107ojb9$1e84t$1@dont-email.me>, >>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>>> On 8/13/2025 4:41 AM, Dan Cross wrote: >>>>>>> In article <107dkai$2rg26$2@dont-email.me>, >>>>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>>> >>>>>> When you get bored, give my lock-free proxy collector a spin... >>>>>> https://pastebin.com/raw/CYZ78gVj >>>>> >>>>> No need, I'm afraid. >>>> >>>> You don't like proxy collectors? Or you think mine is shit? >>> >>> Sorry, I'm just not sure you're a useful source of code like >>> this. It's subtle and requires a lot of in-depth understanding >>> of very thorny issues that it doesn't strike me you have a good >>> handle on. >> >> Fwiw, some of my math is taking notice. An example: >> >> https://paulbourke.net/fractals/multijulia/ >> >> Also, I made it into the cover of the AMS calendar. They even put my >> work on their webpage: >> >> https://www.ams.org/publicoutreach/math-imagery/math-imagery >> >> Notice my name? > > No, I don't. Look again. Notice the graphic on the webpage: https://i.ibb.co/23gKYK0w/image.png They give me credit for my field line render called iWire. > Using their integrated search feature for the > string, "Thomasson" only turns up a few links to an actual > mathematician working on graph theory. I did not write a paper for them. But showed them some of my vector field work, and they said wow! > In fact, most of the links you are posting don't seem to involve > you at all. The only one that actually seems to refer to you is > a short note on Vyukov's page; I have no idea why that's there. > It seems rather old. Well, yeah, its from my old work. Vyukov and I are friends from way back on c.p.t. I helped him find bugs in his Relacy race detector, and we discussed many interesting things, way back 20+ years ago. > Bluntly, I'm really not all that interested. I made the cover of the 2025 AMS Calendar of Mathematical Imagery: https://www.facebook.com/photo/?fbid=1218640825961580&set=pcb.1218640912628238 https://i.ibb.co/TqrhBrjk/image.png Pretty cool!
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-18 23:44 +0000 |
| Message-ID | <1080dsm$dra$1@reader1.panix.com> |
| In reply to | #122578 |
In article <1080bs0$3dqgt$3@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/18/2025 3:56 PM, Dan Cross wrote: >> In article <108067e$3ccku$2@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> Notice my name? >> >> No, I don't. > >Look again. Notice the graphic on the webpage: > >https://i.ibb.co/23gKYK0w/image.png > >They give me credit for my field line render called iWire. Sorry, I'm just not that interested. I don't really see what any of this has to do with C++. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 16:55 -0700 |
| Message-ID | <1080ehn$3ek5d$1@dont-email.me> |
| In reply to | #122581 |
On 8/18/2025 4:44 PM, Dan Cross wrote: > In article <1080bs0$3dqgt$3@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/18/2025 3:56 PM, Dan Cross wrote: >>> In article <108067e$3ccku$2@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> Notice my name? >>> >>> No, I don't. >> >> Look again. Notice the graphic on the webpage: >> >> https://i.ibb.co/23gKYK0w/image.png >> >> They give me credit for my field line render called iWire. > > Sorry, I'm just not that interested. > > I don't really see what any of this has to do with C++. The only thing is I used C++ to implement iWire. ;^) Anyway, I have a lot of experience with lock/wait/obstruction-free algos. A fun part was helping Dmitriy find bugs in his Relacy project when he first created it back on c.p.t.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-18 23:57 +0000 |
| Message-ID | <1080ekr$hie$1@reader1.panix.com> |
| In reply to | #122582 |
In article <1080ehn$3ek5d$1@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/18/2025 4:44 PM, Dan Cross wrote: >> In article <1080bs0$3dqgt$3@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 8/18/2025 3:56 PM, Dan Cross wrote: >>>> In article <108067e$3ccku$2@dont-email.me>, >>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> Notice my name? >>>> >>>> No, I don't. >>> >>> Look again. Notice the graphic on the webpage: >>> >>> https://i.ibb.co/23gKYK0w/image.png >>> >>> They give me credit for my field line render called iWire. >> >> Sorry, I'm just not that interested. >> >> I don't really see what any of this has to do with C++. > >The only thing is I used C++ to implement iWire. ;^) Anyway, I have a >lot of experience with lock/wait/obstruction-free algos. A fun part was >helping Dmitriy find bugs in his Relacy project when he first created it >back on c.p.t. Like I said, I'm not really interested. And besides, this is comp.lang.c++; none of this feels at all relevant. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-19 13:25 -0700 |
| Message-ID | <1082mjg$3ujpq$1@dont-email.me> |
| In reply to | #122583 |
On 8/18/2025 4:57 PM, Dan Cross wrote: > In article <1080ehn$3ek5d$1@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/18/2025 4:44 PM, Dan Cross wrote: >>> In article <1080bs0$3dqgt$3@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 8/18/2025 3:56 PM, Dan Cross wrote: >>>>> In article <108067e$3ccku$2@dont-email.me>, >>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>>> Notice my name? >>>>> >>>>> No, I don't. >>>> >>>> Look again. Notice the graphic on the webpage: >>>> >>>> https://i.ibb.co/23gKYK0w/image.png >>>> >>>> They give me credit for my field line render called iWire. >>> >>> Sorry, I'm just not that interested. >>> >>> I don't really see what any of this has to do with C++. >> >> The only thing is I used C++ to implement iWire. ;^) Anyway, I have a >> lot of experience with lock/wait/obstruction-free algos. A fun part was >> helping Dmitriy find bugs in his Relacy project when he first created it >> back on c.p.t. > > Like I said, I'm not really interested. And besides, this is > comp.lang.c++; none of this feels at all relevant. Fair enough. Fwiw, my proxy collector is pretty interesting, well, to me anyway, and works fine. I need to find my impl of it in Relacy. Who knows, you might like it. If you are ever _really_ bored, I mean no books to read, nothing on tv, nothing to code, nobody to talk to, well, give it a go sometime. If you ever do, please tell be about your experience. Thanks. :^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-15 17:30 -0700 |
| Message-ID | <107ojfk$1e84t$2@dont-email.me> |
| In reply to | #122523 |
On 8/13/2025 4:41 AM, Dan Cross wrote: > In article <107dkai$2rg26$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/9/2025 8:08 PM, Dan Cross wrote: >>> In article <10781l0$1eamj$2@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 8/9/2025 9:08 AM, Dan Cross wrote: >>>>> In article <10775om$17ms4$1@raubtier-asyl.eternal-september.org>, >>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>>> Am 09.08.2025 um 11:17 schrieb Dan Cross: >>>>>> >>>>>>> People have written code that tries to take a lock, and if that >>>>>>> fails, does something else, for decades. The idea is neither >>>>>>> new, nor terribly interesting. Sorry. >>>>>> >>>>>> I think this pattern is extremely rare because the task that needs to >>>>>> be done elsewhere must be able to be omitted completely if necessary, >>>>>> and if not, it must be short enough that it doesn't interfere with >>>>>> waiting for the mutex. >>>>> >>>>> Yeah. That's why I mentioned concentrating on the specific >>>>> critical section the mutex is protecting, not the locking >>>>> protocol. Where this has any utility at all, it's in places >>>>> where the "something else" is well-known, which implies it being >>>>> a function of the critsec. It's going to be things like, "if I >>>>> fail to acquire the scheduler lock, then increment this per-core >>>>> atomic counter that's measuring contention...." sort of thing. >>>> >>>> More grasping at straws and/or trying to breath underwater without scuba >>>> gear... The other work is very specialized. It can be as simple as >>>> processing a per-thread local queue or something. Just something that >>>> can act like a backoff that does real work in a case of contention. Sigh. >>> >>> That's the sort of thing where you cannot know what's on that >>> "per-thread local queue" that makes your scheme fail. >> >> Well, that per-thread local queue can be for organization, maintenance, >> sending the results to a "logic" thread, ect. Think of a server io >> thread that takes the io completions and organizes them into local >> queues. These io threads do not call into user logic, or processing wrt >> say, parsing HTTP, or some protocol. So, some work that can be used >> after a try_lock fails can be to push the local queues to the logic threads. > > This, yet again, seems to be where you don't understand the > issue at stake here. > > You can _probably_ find _any number of things_ that you can do > while looping over `try_lock`. I don't care about the specific > examples: they obviously exist. > > But what you _cannot_ do, and what makes this sort of scheme > fail, is know that _all_ such work is safe. Unless you can wave > a magic wand and solve the halting problem, you won't be able to > know that some jerk won't send you "work" that amounts to a > non-terminating infinite loop. You won't be able to know that > some other jerk hasn't sent you "work" that causes you to > deadlock trying to take a mutex you already hold. Etc. > > If you _ever_ open yourself up to accepting "work" on some kind > of queue, where the types of all work that can possibly be sent > to you is not known in advance _in some way that can be enforced > in code_, then your scheme fails. And if you do have some way > to enforce those constraints, then the scheme is neither novel > nor particularly interesting. > >>> If your lock is contended, you could just sleep on it, and let >>> the kernel schedule something else instead. There's no value to >>> keeping your thread "hot" unless you've got a profile showing >>> that it's an issue. >> >> But why sleep when the thread can do some real work? > > Because the OS (or even a user-level thread scheduler, or > language runtime, or whatever) can find work to usefully do on > that CPU, _without_ the downsides mentioned above. So you lose > nothing but gain correctness and stability. > >> Argh. Grasping >> again. Feels like I am drowning. Shit! ;^o > > Perhaps stop doing that, then. It's clear you are not going to > find a way to make whatever partially developed idea you have > work. It should be okay if the other work is okay with it? > > It's ok to be wrong. It's less ok to keep trying to convince > others that you are right. It just seems to be okay, well, after a try_lock fails try to do something that is _compatible_ instead of something like an adaptive mutex? Shit. Yikes! There I go again. Sorry. [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-18 20:26 +0000 |
| Message-ID | <1080292$h40$2@reader1.panix.com> |
| In reply to | #122540 |
In article <107ojfk$1e84t$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/13/2025 4:41 AM, Dan Cross wrote: >> In article <107dkai$2rg26$2@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 8/9/2025 8:08 PM, Dan Cross wrote: >>>> In article <10781l0$1eamj$2@dont-email.me>, >>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> On 8/9/2025 9:08 AM, Dan Cross wrote: >>>>>> In article <10775om$17ms4$1@raubtier-asyl.eternal-september.org>, >>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>>>> Am 09.08.2025 um 11:17 schrieb Dan Cross: >>>>>>> >>>>>>>> People have written code that tries to take a lock, and if that >>>>>>>> fails, does something else, for decades. The idea is neither >>>>>>>> new, nor terribly interesting. Sorry. >>>>>>> >>>>>>> I think this pattern is extremely rare because the task that needs to >>>>>>> be done elsewhere must be able to be omitted completely if necessary, >>>>>>> and if not, it must be short enough that it doesn't interfere with >>>>>>> waiting for the mutex. >>>>>> >>>>>> Yeah. That's why I mentioned concentrating on the specific >>>>>> critical section the mutex is protecting, not the locking >>>>>> protocol. Where this has any utility at all, it's in places >>>>>> where the "something else" is well-known, which implies it being >>>>>> a function of the critsec. It's going to be things like, "if I >>>>>> fail to acquire the scheduler lock, then increment this per-core >>>>>> atomic counter that's measuring contention...." sort of thing. >>>>> >>>>> More grasping at straws and/or trying to breath underwater without scuba >>>>> gear... The other work is very specialized. It can be as simple as >>>>> processing a per-thread local queue or something. Just something that >>>>> can act like a backoff that does real work in a case of contention. Sigh. >>>> >>>> That's the sort of thing where you cannot know what's on that >>>> "per-thread local queue" that makes your scheme fail. >>> >>> Well, that per-thread local queue can be for organization, maintenance, >>> sending the results to a "logic" thread, ect. Think of a server io >>> thread that takes the io completions and organizes them into local >>> queues. These io threads do not call into user logic, or processing wrt >>> say, parsing HTTP, or some protocol. So, some work that can be used >>> after a try_lock fails can be to push the local queues to the logic threads. >> >> This, yet again, seems to be where you don't understand the >> issue at stake here. >> >> You can _probably_ find _any number of things_ that you can do >> while looping over `try_lock`. I don't care about the specific >> examples: they obviously exist. >> >> But what you _cannot_ do, and what makes this sort of scheme >> fail, is know that _all_ such work is safe. Unless you can wave >> a magic wand and solve the halting problem, you won't be able to >> know that some jerk won't send you "work" that amounts to a >> non-terminating infinite loop. You won't be able to know that >> some other jerk hasn't sent you "work" that causes you to >> deadlock trying to take a mutex you already hold. Etc. >> >> If you _ever_ open yourself up to accepting "work" on some kind >> of queue, where the types of all work that can possibly be sent >> to you is not known in advance _in some way that can be enforced >> in code_, then your scheme fails. And if you do have some way >> to enforce those constraints, then the scheme is neither novel >> nor particularly interesting. >> >>>> If your lock is contended, you could just sleep on it, and let >>>> the kernel schedule something else instead. There's no value to >>>> keeping your thread "hot" unless you've got a profile showing >>>> that it's an issue. >>> >>> But why sleep when the thread can do some real work? >> >> Because the OS (or even a user-level thread scheduler, or >> language runtime, or whatever) can find work to usefully do on >> that CPU, _without_ the downsides mentioned above. So you lose >> nothing but gain correctness and stability. >> >>> Argh. Grasping >>> again. Feels like I am drowning. Shit! ;^o >> >> Perhaps stop doing that, then. It's clear you are not going to >> find a way to make whatever partially developed idea you have >> work. > >It should be okay if the other work is okay with it? Again: you have no way of knowing that "the other work is okay with it". >> It's ok to be wrong. It's less ok to keep trying to convince >> others that you are right. > >It just seems to be okay, well, after a try_lock fails try to do >something that is _compatible_ instead of something like an adaptive >mutex? Shit. Yikes! > >There I go again. Sorry. > >[...] Please stop. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web