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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 13:39 -0700 |
| Message-ID | <108031c$3bdl8$2@dont-email.me> |
| In reply to | #122565 |
On 8/18/2025 1:26 PM, Dan Cross wrote: > 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". Sure you can in highly controlled scenarios? A programmer can say, this type of work can be done in this condition because the programmer knows what the work consists of... I listed a few of them before. I am not going for some sort of general case type of thing. >>> 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. It sure seems like it cannot be 100% wrong all the time. Having trouble seeing that.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-18 20:44 +0000 |
| Message-ID | <10803bq$h40$4@reader1.panix.com> |
| In reply to | #122567 |
In article <108031c$3bdl8$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/18/2025 1:26 PM, Dan Cross wrote: >> 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". > >Sure you can in highly controlled scenarios? A programmer can say, this >type of work can be done in this condition because the programmer knows >what the work consists of... I listed a few of them before. I am not >going for some sort of general case type of thing. > > >>>> 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. > >It sure seems like it cannot be 100% wrong all the time. Having trouble >seeing that. It's already in the above quoted text. The relevant section is 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. Just saying, "yay! I can do something while spinning on a lock!" is so vaccuously obvious that it's simply uninteresting; people have done such things for many, many years. Your error is in trying to extrapolate that to "other" work. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 14:08 -0700 |
| Message-ID | <10804np$3bdl8$4@dont-email.me> |
| In reply to | #122569 |
On 8/18/2025 1:44 PM, Dan Cross wrote: > In article <108031c$3bdl8$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/18/2025 1:26 PM, Dan Cross wrote: >>> 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". >> >> Sure you can in highly controlled scenarios? A programmer can say, this >> type of work can be done in this condition because the programmer knows >> what the work consists of... I listed a few of them before. I am not >> going for some sort of general case type of thing. >> >> >>>>> 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. >> >> It sure seems like it cannot be 100% wrong all the time. Having trouble >> seeing that. > > It's already in the above quoted text. The relevant section is > 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. > > Just saying, "yay! I can do something while spinning on a lock!" > is so vaccuously obvious that it's simply uninteresting; people > have done such things for many, many years. Your error is in > trying to extrapolate that to "other" work. So be it. Although, this convo gave this group a little action, so to speak? :^) Anyway, I have a lot of experience with lock/wait free algos.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 16:11 -0700 |
| Message-ID | <1080bvs$3e5uq$1@dont-email.me> |
| In reply to | #122569 |
On 8/18/2025 1:44 PM, Dan Cross wrote: > In article <108031c$3bdl8$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/18/2025 1:26 PM, Dan Cross wrote: >>> 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". >> >> Sure you can in highly controlled scenarios? A programmer can say, this >> type of work can be done in this condition because the programmer knows >> what the work consists of... I listed a few of them before. I am not >> going for some sort of general case type of thing. >> >> >>>>> 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. >> >> It sure seems like it cannot be 100% wrong all the time. Having trouble >> seeing that. > > It's already in the above quoted text. The relevant section is > 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. > > Just saying, "yay! I can do something while spinning on a lock!" > is so vaccuously obvious that it's simply uninteresting; people > have done such things for many, many years. Your error is in > trying to extrapolate that to "other" work. > > - Dan C. > It was fun when Sun gave me a T2000 SunFire server wrt to their CoolThreads contest.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-18 16:20 -0700 |
| Message-ID | <1080cg5$3e5uq$2@dont-email.me> |
| In reply to | #122569 |
On 8/18/2025 1:44 PM, Dan Cross wrote: [...] I remember a really old Intel white paper mentioned my old AppCore work. But, I cannot find it. Sigh.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-11 11:04 +0200 |
| Message-ID | <107cbmn$2eh3o$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122504 |
Am 09.08.2025 um 19:48 schrieb Chris M. Thomasson: > 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. Interesting that you can't think of anything specific about the task that could otherwise be done, just vague stuff.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-11 13:30 -0700 |
| Message-ID | <107djsh$2rg26$1@dont-email.me> |
| In reply to | #122510 |
On 8/11/2025 2:04 AM, Bonita Montero wrote: > Am 09.08.2025 um 19:48 schrieb Chris M. Thomasson: > >> 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. > > Interesting that you can't think of anything specific about > the task that could otherwise be done, just vague stuff. I gave some quick examples, perhaps you missed them. It could be batching thread local queues, checking to see if an GetQueuedCompletionStatusEx (timeout 0) succeeds, perhaps something that does not call into user code, stuff like that... Wrt batching, think if a server worker thread has separate local queues for accepts, connects, sends, recvs... Batching is beneficial, and GetQueuedCompletionStatusEx (GQCSEX) can return multiple io's at once. There is an old paper about it called stagedserver: https://www.cs.cmu.edu/~StagedDB/papers/CMU-CS-02-113.pdf So, stuffing the results from GQCSEX into local queues allows for this. The other work is going to be specialized. So, a programmer can say well, if the try_lock fails, lets try this instead.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-12 10:23 +0200 |
| Message-ID | <107etks$350fs$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122511 |
Am 11.08.2025 um 22:30 schrieb Chris M. Thomasson: > I gave some quick examples, perhaps you missed them. It could be > batching thread local queues, checking to see if an > GetQueuedCompletionStatusEx (timeout 0) succeeds, ... GetQueuedCompletionStatusEx() is an expensive kernel call, not something you do casually. Even a Sleep( 0 ), which is equivalent to a std:: this_thread::yield(), costs about 1,000 clock cycles on a modern CPU. And GetQueuedCompletionStatusEx() isn't a function whose execution can be arbitrarily delayed or even prevented altogether. In other words: You're simply overthinking.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-12 01:31 -0700 |
| Message-ID | <107eu5g$33jcr$5@dont-email.me> |
| In reply to | #122515 |
On 8/12/2025 1:23 AM, Bonita Montero wrote: > Am 11.08.2025 um 22:30 schrieb Chris M. Thomasson: > >> I gave some quick examples, perhaps you missed them. It could be >> batching thread local queues, checking to see if an >> GetQueuedCompletionStatusEx (timeout 0) succeeds, ... > > GetQueuedCompletionStatusEx() is an expensive kernel call, not something > you do casually. Even a Sleep( 0 ), which is equivalent to a std:: > this_thread::yield(), costs about 1,000 clock cycles on a modern CPU. > And GetQueuedCompletionStatusEx() isn't a function whose execution can > be arbitrarily delayed or even prevented altogether. In other words: > You're simply overthinking. Its seems quite fine though. try_lock fails... Sometimes go for a GetQueuedCompletionStatusEx with a 0 timeout. Vs just going into the kernel anyway for the contention. Try some local queues before trying GetQueuedCompletionStatusEx a couple of times in the backoff, Or spinning ala adaptive mutex logic doing nothing anyway... If it succeeds we get to sort the results into their per thread queues, if not, we lock. If it succeeds too (too much work) many times we lock. If try lock does not fail, well we got the damn lock anyway. So be it?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-12 10:39 +0200 |
| Message-ID | <107eujh$35885$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122516 |
Am 12.08.2025 um 10:31 schrieb Chris M. Thomasson:
> Its seems quite fine though. try_lock fails... Sometimes go for a
> GetQueuedCompletionStatusEx with a 0 timeout.
I've tried that:
#include <Windows.h>
#include <iostream>
#include <chrono>
using namespace std;
using namespace chrono;
int main()
{
HANDLE hFile = CreateFileA( "bla.txt", GENERIC_READ | GENERIC_WRITE, 0,
nullptr, CREATE_ALWAYS, FILE_FLAG_OVERLAPPED, NULL );
if( hFile == INVALID_HANDLE_VALUE )
return EXIT_FAILURE;
HANDLE hIocp = CreateIoCompletionPort( hFile, NULL, NULL, 1 );
if( !hIocp )
return EXIT_FAILURE;
auto start = high_resolution_clock::now();
for( size_t r = 1'000'000; r; --r )
{
SetLastError( NO_ERROR );
DWORD dwTransferred;
ULONG_PTR ulpKey = 0;
OVERLAPPED *pOl = nullptr;
if( !GetQueuedCompletionStatus( hIocp, &dwTransferred, &ulpKey, &pOl,
0 ) && GetLastError() != WAIT_TIMEOUT )
return EXIT_FAILURE;
}
cout << (double)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count() / 1.0e6 << endl;
}
On my Zen4-CPU the immediately timeouted GetQueuedCompletionStatus() is
about 226ms. Do you still think you're right ? You've too much phantasy.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-12 01:45 -0700 |
| Message-ID | <107euuv$33jcr$7@dont-email.me> |
| In reply to | #122517 |
On 8/12/2025 1:39 AM, Bonita Montero wrote:
> Am 12.08.2025 um 10:31 schrieb Chris M. Thomasson:
>
>> Its seems quite fine though. try_lock fails... Sometimes go for a
>> GetQueuedCompletionStatusEx with a 0 timeout.
>
> I've tried that:
>
> #include <Windows.h>
> #include <iostream>
> #include <chrono>
>
> using namespace std;
> using namespace chrono;
>
> int main()
> {
> HANDLE hFile = CreateFileA( "bla.txt", GENERIC_READ |
> GENERIC_WRITE, 0, nullptr, CREATE_ALWAYS, FILE_FLAG_OVERLAPPED, NULL );
> if( hFile == INVALID_HANDLE_VALUE )
> return EXIT_FAILURE;
> HANDLE hIocp = CreateIoCompletionPort( hFile, NULL, NULL, 1 );
> if( !hIocp )
> return EXIT_FAILURE;
> auto start = high_resolution_clock::now();
> for( size_t r = 1'000'000; r; --r )
> {
> SetLastError( NO_ERROR );
> DWORD dwTransferred;
> ULONG_PTR ulpKey = 0;
> OVERLAPPED *pOl = nullptr;
> if( !GetQueuedCompletionStatus( hIocp, &dwTransferred, &ulpKey,
> &pOl, 0 ) && GetLastError() != WAIT_TIMEOUT )
> return EXIT_FAILURE;
> }
> cout <<
> (double)duration_cast<nanoseconds>( high_resolution_clock::now() -
> start ).count() / 1.0e6 << endl;
> }
>
> On my Zen4-CPU the immediately timeouted GetQueuedCompletionStatus() is
> about 226ms. Do you still think you're right ? You've too much phantasy.
>
>
So, other threads could have tried the mutex by then, or shit happens.
Hopefully the system would be loaded to where the probability of
GetQueuedCompletionStatusEx returning something would be high. Or,
perhaps try per-thread local data-structures first for a couple of spins
failing on try_lock, then try a GetQueuedCompletionStatusEx, then say
oh my try_lock still failed, lock.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-12 10:56 +0200 |
| Message-ID | <107evjv$35g2q$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122518 |
Am 12.08.2025 um 10:45 schrieb Chris M. Thomasson: > So, other threads could have tried the mutex by then, or shit happens. The idea is simply nonsense. > Hopefully the system would be loaded to where the probability of > GetQueuedCompletionStatusEx returning something would be high. Or, > perhaps try per-thread local data-structures first for a couple of spins > failing on try_lock, then try a GetQueuedCompletionStatusEx, then say > oh my try_lock still failed, lock. >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-12 02:14 -0700 |
| Message-ID | <107f0m0$34lkn$2@dont-email.me> |
| In reply to | #122519 |
On 8/12/2025 1:56 AM, Bonita Montero wrote: > Am 12.08.2025 um 10:45 schrieb Chris M. Thomasson: > >> So, other threads could have tried the mutex by then, or shit happens. > > The idea is simply nonsense. Are you 100% sure about that? Thread A try_lock failed. It tries and fails on a GQCSEX. In the mean time threads B...G have taken the lock, done their thing, and released it. Or the other path. Thread A tries again, fails, nothing to do, or back off exceeded, then calls lock. Thread A try_lock failed. GQCSEX succeeds and it gets to sort its io completions into per-thread queues, ect, then try_lock again. Other threads could have already locked and unlocked the mutex, but the thread A did real work, and its try_lock succeeds! It did not have to spin doing nothing and it did not have to wait in the kernel doing nothing, ect, ect... > >> Hopefully the system would be loaded to where the probability of >> GetQueuedCompletionStatusEx returning something would be high. Or, >> perhaps try per-thread local data-structures first for a couple of >> spins failing on try_lock, then try a GetQueuedCompletionStatusEx, >> then say oh my try_lock still failed, lock. >> >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-12 15:08 +0200 |
| Message-ID | <107feb8$3952n$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122520 |
Am 12.08.2025 um 11:14 schrieb Chris M. Thomasson: > On 8/12/2025 1:56 AM, Bonita Montero wrote: >> Am 12.08.2025 um 10:45 schrieb Chris M. Thomasson: >> >>> So, other threads could have tried the mutex by then, or shit happens. >> >> The idea is simply nonsense. > > Are you 100% sure about that? You need a task that is some nanoseconds only and that can be completely omitted if locking succeeds. That never happens. > > Thread A try_lock failed. It tries and fails on a GQCSEX. In the mean > time threads B...G have taken the lock, done their thing, and released > it. Or the other path. Thread A tries again, fails, nothing to do, or > back off exceeded, then calls lock. > > Thread A try_lock failed. GQCSEX succeeds and it gets to sort its io > completions into per-thread queues, ect, then try_lock again. Other > threads could have already locked and unlocked the mutex, but the thread > A did real work, and its try_lock succeeds! It did not have to spin > doing nothing and it did not have to wait in the kernel doing nothing, > ect, ect... > > >> >>> Hopefully the system would be loaded to where the probability of >>> GetQueuedCompletionStatusEx returning something would be high. Or, >>> perhaps try per-thread local data-structures first for a couple of >>> spins failing on try_lock, then try a GetQueuedCompletionStatusEx, >>> then say oh my try_lock still failed, lock. >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-15 21:36 -0700 |
| Message-ID | <107p1t7$1grpk$1@dont-email.me> |
| In reply to | #122521 |
On 8/12/2025 6:08 AM, Bonita Montero wrote: > Am 12.08.2025 um 11:14 schrieb Chris M. Thomasson: >> On 8/12/2025 1:56 AM, Bonita Montero wrote: >>> Am 12.08.2025 um 10:45 schrieb Chris M. Thomasson: >>> >>>> So, other threads could have tried the mutex by then, or shit happens. >>> >>> The idea is simply nonsense. >> >> Are you 100% sure about that? > > You need a task that is some nanoseconds only and that can be completely > omitted if locking succeeds. That never happens. Not totally true. Other _compatible_ work can be akin to a backoff, say in an adaptive mutex. It's far a few between, but it can be usefull in certian scenarios. When a try_lock fails it means another thread is making progress. > > >> >> Thread A try_lock failed. It tries and fails on a GQCSEX. In the mean >> time threads B...G have taken the lock, done their thing, and released >> it. Or the other path. Thread A tries again, fails, nothing to do, or >> back off exceeded, then calls lock. >> >> Thread A try_lock failed. GQCSEX succeeds and it gets to sort its io >> completions into per-thread queues, ect, then try_lock again. Other >> threads could have already locked and unlocked the mutex, but the >> thread A did real work, and its try_lock succeeds! It did not have to >> spin doing nothing and it did not have to wait in the kernel doing >> nothing, ect, ect... >> >> >>> >>>> Hopefully the system would be loaded to where the probability of >>>> GetQueuedCompletionStatusEx returning something would be high. Or, >>>> perhaps try per-thread local data-structures first for a couple of >>>> spins failing on try_lock, then try a GetQueuedCompletionStatusEx, >>>> then say oh my try_lock still failed, lock. >>>> >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-16 10:13 +0200 |
| Message-ID | <107pehp$1jfeh$4@raubtier-asyl.eternal-september.org> |
| In reply to | #122541 |
Am 16.08.2025 um 06:36 schrieb Chris M. Thomasson: > On 8/12/2025 6:08 AM, Bonita Montero wrote: >> You need a task that is some nanoseconds only and that can be completely >> omitted if locking succeeds. That never happens. > Not totally true. Other _compatible_ work can be akin to a backoff, say > in an adaptive mutex. It's far a few between, but it can be usefull in > certian scenarios. When a try_lock fails it means another thread is > making progress. Show me a *practical* example of a task that is short in the mentioned dimensions (a few nanoseconds) and that can be completely omitted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-16 01:56 -0700 |
| Message-ID | <107ph4a$1jvf8$1@dont-email.me> |
| In reply to | #122542 |
On 8/16/2025 1:13 AM, Bonita Montero wrote: > Am 16.08.2025 um 06:36 schrieb Chris M. Thomasson: > >> On 8/12/2025 6:08 AM, Bonita Montero wrote: > >>> You need a task that is some nanoseconds only and that can be completely >>> omitted if locking succeeds. That never happens. > >> Not totally true. Other _compatible_ work can be akin to a backoff, >> say in an adaptive mutex. It's far a few between, but it can be >> usefull in certian scenarios. When a try_lock fails it means another >> thread is making progress. > > Show me a *practical* example of a task that is short in the mentioned > dimensions (a few nanoseconds) and that can be completely omitted. Well, why does it have to be a few nanoseconds? Anyway, say pop from a stack using atomic exchange?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-16 11:05 +0200 |
| Message-ID | <107phkn$1k5l2$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122543 |
Am 16.08.2025 um 10:56 schrieb Chris M. Thomasson: > On 8/16/2025 1:13 AM, Bonita Montero wrote: >> Am 16.08.2025 um 06:36 schrieb Chris M. Thomasson: >> >>> On 8/12/2025 6:08 AM, Bonita Montero wrote: >> >>>> You need a task that is some nanoseconds only and that can be >>>> completely >>>> omitted if locking succeeds. That never happens. >> >>> Not totally true. Other _compatible_ work can be akin to a backoff, >>> say in an adaptive mutex. It's far a few between, but it can be >>> usefull in certian scenarios. When a try_lock fails it means another >>> thread is making progress. >> >> Show me a *practical* example of a task that is short in the mentioned >> dimensions (a few nanoseconds) and that can be completely omitted. > > Well, why does it have to be a few nanoseconds? Yes, to delay the locking o the mutex not too long. Show me a paper desribing your idea. > Anyway, say pop from a stack using atomic exchange? And this can be completely omitted ? Your idea is simply silly.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-16 13:31 -0700 |
| Message-ID | <107qprj$1tg2i$2@dont-email.me> |
| In reply to | #122544 |
On 8/16/2025 2:05 AM, Bonita Montero wrote: > Am 16.08.2025 um 10:56 schrieb Chris M. Thomasson: >> On 8/16/2025 1:13 AM, Bonita Montero wrote: >>> Am 16.08.2025 um 06:36 schrieb Chris M. Thomasson: >>> >>>> On 8/12/2025 6:08 AM, Bonita Montero wrote: >>> >>>>> You need a task that is some nanoseconds only and that can be >>>>> completely >>>>> omitted if locking succeeds. That never happens. >>> >>>> Not totally true. Other _compatible_ work can be akin to a backoff, >>>> say in an adaptive mutex. It's far a few between, but it can be >>>> usefull in certian scenarios. When a try_lock fails it means another >>>> thread is making progress. >>> >>> Show me a *practical* example of a task that is short in the mentioned >>> dimensions (a few nanoseconds) and that can be completely omitted. >> >> Well, why does it have to be a few nanoseconds? > > Yes, to delay the locking o the mutex not too long. To delay possibly doing other real work. Think of messing with the backoff count of an adaptive mutex that spins in userspace doing nothing before resorting to the kernel? > Show me a paper desribing your idea. Humm... Need to search. Maybe a paper on what not to do? lol. Anyway, if try_lock fails it means another thread is doing real work, agreed? So, why should the thread that got a try_lock failure be banned from trying to do other real work? Humm... >> Anyway, say pop from a stack using atomic exchange? > > And this can be completely omitted ? > Your idea is simply silly. Popping an atomic stack using a single exchange is fine and normal. That right there can be a productive backoff if the result of the pop was non-null... ? The backoff that does productive work does not necessarily need that mutex, now, now, now... It's doing other real work in the mean time, during contention? Kind of fair "enough" is a sense? Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-17 14:50 +0200 |
| Message-ID | <107sj4t$2a4t9$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122548 |
Am 16.08.2025 um 22:31 schrieb Chris M. Thomasson: > On 8/16/2025 2:05 AM, Bonita Montero wrote: >> And this can be completely omitted ? >> Your idea is simply silly. > Popping an atomic stack using a single exchange is fine and normal. That > right there can be a productive backoff if the result of the pop was > non-null... ? Is this an answer to my question ? No one has published your idea before; it's nonsense.
[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