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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-17 13:43 -0700 |
| Message-ID | <107tetc$2j5rd$1@dont-email.me> |
| In reply to | #122552 |
On 8/17/2025 5:50 AM, Bonita Montero wrote: > 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 ? Yeah. > > No one has published your idea before; it's nonsense. > 99% nonsense or 99.(9)% nonsense? ;^)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-13 11:45 +0000 |
| Message-ID | <107htt6$bq7$2@reader1.panix.com> |
| In reply to | #122516 |
In article <107eu5g$33jcr$5@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >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? I don't think you have a good handle on the relative cost of these operations. You seem to be against spending a few cycles spinning, or against paying the one time cost of going to sleep in the kernel until your mutex is available, but willing to burn thousands of cycles going into the kernel over and over again to see if an IO port becomes ready so that you can keep your thread "hot". That's, frankly, not at all a good tradeoff. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-13 19:07 +0200 |
| Message-ID | <107ignu$qsr$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122524 |
Am 13.08.2025 um 13:45 schrieb Dan Cross: > I don't think you have a good handle on the relative cost of > these operations. > > You seem to be against spending a few cycles spinning, or > against paying the one time cost of going to sleep in the kernel > until your mutex is available, but willing to burn thousands of > cycles going into the kernel over and over again to see if an IO > port becomes ready so that you can keep your thread "hot". > > That's, frankly, not at all a good tradeoff. Chris has too much phantasy.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-08-13 17:31 +0000 |
| Message-ID | <IZ3nQ.5691$D%M7.4113@fx33.iad> |
| In reply to | #122526 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 13.08.2025 um 13:45 schrieb Dan Cross: > >> I don't think you have a good handle on the relative cost of >> these operations. >> >> You seem to be against spending a few cycles spinning, or >> against paying the one time cost of going to sleep in the kernel >> until your mutex is available, but willing to burn thousands of >> cycles going into the kernel over and over again to see if an IO >> port becomes ready so that you can keep your thread "hot". >> >> That's, frankly, not at all a good tradeoff. > >Chris has too much phantasy. Du bist zu kritisch.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-15 10:00 -0700 |
| Message-ID | <107np30$182ho$2@dont-email.me> |
| In reply to | #122527 |
On 8/13/2025 10:31 AM, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 13.08.2025 um 13:45 schrieb Dan Cross: >> >>> I don't think you have a good handle on the relative cost of >>> these operations. >>> >>> You seem to be against spending a few cycles spinning, or >>> against paying the one time cost of going to sleep in the kernel >>> until your mutex is available, but willing to burn thousands of >>> cycles going into the kernel over and over again to see if an IO >>> port becomes ready so that you can keep your thread "hot". >>> >>> That's, frankly, not at all a good tradeoff. >> >> Chris has too much phantasy. > > Du bist zu kritisch. Well, the pattern only shines when the other work is actually compatible with it. For instance, if the other work blocks on say, io, well, that would be bad.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-13 12:41 -0700 |
| Message-ID | <107ipp7$2c02$1@dont-email.me> |
| In reply to | #122526 |
On 8/13/2025 10:07 AM, Bonita Montero wrote: > Am 13.08.2025 um 13:45 schrieb Dan Cross: > >> I don't think you have a good handle on the relative cost of >> these operations. >> >> You seem to be against spending a few cycles spinning, or >> against paying the one time cost of going to sleep in the kernel >> until your mutex is available, but willing to burn thousands of >> cycles going into the kernel over and over again to see if an IO >> port becomes ready so that you can keep your thread "hot". >> >> That's, frankly, not at all a good tradeoff. > > Chris has too much phantasy. > Shit can happen! ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-09 10:44 -0700 |
| Message-ID | <10781e3$1eamj$1@dont-email.me> |
| In reply to | #122500 |
On 8/9/2025 2:17 AM, Dan Cross wrote: > In article <1073snp$en4a$3@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 8/7/2025 6:49 PM, Dan Cross wrote: >>> In article <1070m2s$3lg2n$4@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> [snip] >>>> carefully is the key concept! Yikes... Shit... However, basically, it >>>> still boils down to trying other "work" on a spin can keep the thread >>>> "hot" doing other work, instead of spinning on an adaptive logic of a >>>> mutex, nothing nothing? >>> >>> Keeping a thread "hot" without being able to make any sort of >>> meaningful guarantee about the viability of the scheme as a >>> general mechanism is not useful, when considering the scheme as >>> a general mechanism. >> >> general mechanism? No. Oh no. I am no trying to do that at all. How >> about a sometimes it might be okay type of scenario? Argh! My mind keeps >> on thinking of other work that will not spin off into never never land, >> the nightmare thing I mentioned. It will not deadlock, actually, not >> sure how it could deadlock in this highly special realm, anyway... That >> call to a try IOCP means that is has the "chance" to gain data, checking >> a thread local queues has a chance to have other work while the mutex is >> in contention anyway via try_lock fail? Oh my.... I am grasping at >> straws here.. But, it still might be okay for certain scenarios? > > Yes, you are grasping at straws. > > 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. Oh well. At least we had a nice conversation about it. thanks. :^) >> Actually, way back, 20-25 years ago when I was messing around with proxy >> collectors... I had a base case that used mutexes only. No fancy >> atomics, ect... Pre C++11, ect... It worked. If a per thread mutex >> try_lock failed it meant a reaper thread got a hold of it, and it should >> lock its next generation of mutexes. all per thread. This would allow >> for a RCU type of setup using mutexes only. Pretty fun. > > That vague, incomplete description sounds nothing like how RCU > works. It's a way to get a proxy collector (RCU like) using two sets of per-thread locks. It was an older test bench to see how a mutex version compared against a lock-free version. Have you taken a look at my proxy collector? Here is an older one: https://pastebin.com/raw/CYZ78gVj
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-09 11:00 -0700 |
| Message-ID | <10782c1$1eamj$3@dont-email.me> |
| In reply to | #122503 |
On 8/9/2025 10:44 AM, Chris M. Thomasson wrote: > On 8/9/2025 2:17 AM, Dan Cross wrote: >> In article <1073snp$en4a$3@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 8/7/2025 6:49 PM, Dan Cross wrote: >>>> In article <1070m2s$3lg2n$4@dont-email.me>, >>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> [snip] >>>>> carefully is the key concept! Yikes... Shit... However, basically, it >>>>> still boils down to trying other "work" on a spin can keep the thread >>>>> "hot" doing other work, instead of spinning on an adaptive logic of a >>>>> mutex, nothing nothing? >>>> >>>> Keeping a thread "hot" without being able to make any sort of >>>> meaningful guarantee about the viability of the scheme as a >>>> general mechanism is not useful, when considering the scheme as >>>> a general mechanism. >>> >>> general mechanism? No. Oh no. I am no trying to do that at all. How >>> about a sometimes it might be okay type of scenario? Argh! My mind keeps >>> on thinking of other work that will not spin off into never never land, >>> the nightmare thing I mentioned. It will not deadlock, actually, not >>> sure how it could deadlock in this highly special realm, anyway... That >>> call to a try IOCP means that is has the "chance" to gain data, checking >>> a thread local queues has a chance to have other work while the mutex is >>> in contention anyway via try_lock fail? Oh my.... I am grasping at >>> straws here.. But, it still might be okay for certain scenarios? >> >> Yes, you are grasping at straws. >> >> 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. > > Oh well. At least we had a nice conversation about it. thanks. :^) > > >>> Actually, way back, 20-25 years ago when I was messing around with proxy >>> collectors... I had a base case that used mutexes only. No fancy >>> atomics, ect... Pre C++11, ect... It worked. If a per thread mutex >>> try_lock failed it meant a reaper thread got a hold of it, and it should >>> lock its next generation of mutexes. all per thread. This would allow >>> for a RCU type of setup using mutexes only. Pretty fun. >> >> That vague, incomplete description sounds nothing like how RCU >> works. > > It's a way to get a proxy collector (RCU like) using two sets of per- > thread locks. It was an older test bench to see how a mutex version > compared against a lock-free version. Have you taken a look at my proxy > collector? Here is an older one: > > https://pastebin.com/raw/CYZ78gVj > The test in there allows a lock-free stack to be iterated without any worry about a node being destroyed during iteration. Also, the reads do not interfere with the writes and vice versa. So, it is RCU-like. Actually, it eliminates the need for an ABA counter such that the lock-free stack can use a single word. It's a fun experiment. When you get really bored, give it a go? Thanks Dan. Its pretty fun, well, to me anyway. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-08-05 10:27 +0200 |
| Message-ID | <106sf9a$2l4e8$1@dont-email.me> |
| In reply to | #122457 |
Op 04.aug.2025 om 21:34 schreef Chris M. Thomasson: > On 8/4/2025 1:48 AM, Muttley@DastardlyHQ.org wrote: >> On Sat, 2 Aug 2025 12:58:23 -0700 >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wibbled: >>> On 7/29/2025 10:54 PM, Chris M. Thomasson wrote: >>>> This is using the idea of trying to do other work while a mutex is >>>> contended. Why spin or wait when we don't really have to? The per- >>>> thread >>>> random numbers in this experiment are only there to try to simulate >>>> when >>>> a contended thread has any other work to do. This can be check per- >>>> thread stacks, queues, ect... Here is my example code. Can you get >>>> it to >>>> run, and can you show me the output? Now, this can work in real world >>>> environments. It's a stare to an adaptive mutex that just spins doing >>>> nothing... lol... ;^) >>>> >>>> I compiled it using c++20 >>>> >>>> (read all...) >>> [snip code] >>>> Any luck? Its fun to see how many work items were completed when the >>>> mutex was contended... >>> >>> I guess the main point is that if a try_lock() fails, then we can _try_ >>> to do "other" work... That can be checking thread local queues, stacks, >> >> I never really understood the point of this semi-sequential paradigm. >> If you >> have other work to do then do it in another thread, thats the whole >> point of >> threading! > > This already works with multiple threads, no problem. But, if a thread > fails to acquire the mutex, it can check to see if it has any other work > to do instead of just waiting in the kernel doing nothing, or spinning > doing nothing... Make sense to you? > > >> Meanwhile if a thread needs to wait for a lock then just let it wait. >> > > The idea is instead of letting it wait, why not let it try to do some > other work? Think of an adaptive mutex. On contention it will spin for a > bounded number of times in user space before having to wait in the > kernel. Well, instead of spinning, try to do something else, some real > work? It will keep the thread hot, doing work instead of just waiting... > > Maybe in old single processor systems it could be useful to avoid spinning and make the processor available for other work. Nowadays each system has many processors and if one of them spins for a brief period, that is not a problem. The work that can be done when one thread is spinning, can be done in other threads. So, the need for such a complicated solution might be present only in very exceptional cases.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-05 16:07 -0700 |
| Message-ID | <106u2s1$31pq8$2@dont-email.me> |
| In reply to | #122462 |
On 8/5/2025 1:27 AM, Fred. Zwarts wrote: > Op 04.aug.2025 om 21:34 schreef Chris M. Thomasson: >> On 8/4/2025 1:48 AM, Muttley@DastardlyHQ.org wrote: >>> On Sat, 2 Aug 2025 12:58:23 -0700 >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wibbled: >>>> On 7/29/2025 10:54 PM, Chris M. Thomasson wrote: >>>>> This is using the idea of trying to do other work while a mutex is >>>>> contended. Why spin or wait when we don't really have to? The per- >>>>> thread >>>>> random numbers in this experiment are only there to try to simulate >>>>> when >>>>> a contended thread has any other work to do. This can be check per- >>>>> thread stacks, queues, ect... Here is my example code. Can you get >>>>> it to >>>>> run, and can you show me the output? Now, this can work in real world >>>>> environments. It's a stare to an adaptive mutex that just spins doing >>>>> nothing... lol... ;^) >>>>> >>>>> I compiled it using c++20 >>>>> >>>>> (read all...) >>>> [snip code] >>>>> Any luck? Its fun to see how many work items were completed when the >>>>> mutex was contended... >>>> >>>> I guess the main point is that if a try_lock() fails, then we can _try_ >>>> to do "other" work... That can be checking thread local queues, stacks, >>> >>> I never really understood the point of this semi-sequential paradigm. >>> If you >>> have other work to do then do it in another thread, thats the whole >>> point of >>> threading! >> >> This already works with multiple threads, no problem. But, if a thread >> fails to acquire the mutex, it can check to see if it has any other >> work to do instead of just waiting in the kernel doing nothing, or >> spinning doing nothing... Make sense to you? >> >> >>> Meanwhile if a thread needs to wait for a lock then just let it wait. >>> >> >> The idea is instead of letting it wait, why not let it try to do some >> other work? Think of an adaptive mutex. On contention it will spin for >> a bounded number of times in user space before having to wait in the >> kernel. Well, instead of spinning, try to do something else, some real >> work? It will keep the thread hot, doing work instead of just waiting... >> >> > Maybe in old single processor systems it could be useful to avoid > spinning and make the processor available for other work. > Nowadays each system has many processors and if one of them spins for a > brief period, that is not a problem. The work that can be done when one > thread is spinning, can be done in other threads. > So, the need for such a complicated solution might be present only in > very exceptional cases. Say the mutex is not all that "critical" to grab. Also, the backoff limit is there to make sure that the mutex shall be acquired. Also, a lot of this other work can be thread local, so another thread cannot start working on it? When the mutex is acquired a thread can do some interesting things. Check global state, check for update commands, to update the server, ect... But, the point is that when the mutex is not able to be locked, the thread will at least try to do something else? Is this okay, or just pie in the sky crap?
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-08-06 10:56 +0200 |
| Message-ID | <106v5cs$38rch$1@dont-email.me> |
| In reply to | #122465 |
Op 06.aug.2025 om 01:07 schreef Chris M. Thomasson: > On 8/5/2025 1:27 AM, Fred. Zwarts wrote: >> Op 04.aug.2025 om 21:34 schreef Chris M. Thomasson: >>> On 8/4/2025 1:48 AM, Muttley@DastardlyHQ.org wrote: >>>> On Sat, 2 Aug 2025 12:58:23 -0700 >>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wibbled: >>>>> On 7/29/2025 10:54 PM, Chris M. Thomasson wrote: >>>>>> This is using the idea of trying to do other work while a mutex is >>>>>> contended. Why spin or wait when we don't really have to? The per- >>>>>> thread >>>>>> random numbers in this experiment are only there to try to >>>>>> simulate when >>>>>> a contended thread has any other work to do. This can be check per- >>>>>> thread stacks, queues, ect... Here is my example code. Can you get >>>>>> it to >>>>>> run, and can you show me the output? Now, this can work in real world >>>>>> environments. It's a stare to an adaptive mutex that just spins doing >>>>>> nothing... lol... ;^) >>>>>> >>>>>> I compiled it using c++20 >>>>>> >>>>>> (read all...) >>>>> [snip code] >>>>>> Any luck? Its fun to see how many work items were completed when the >>>>>> mutex was contended... >>>>> >>>>> I guess the main point is that if a try_lock() fails, then we can >>>>> _try_ >>>>> to do "other" work... That can be checking thread local queues, >>>>> stacks, >>>> >>>> I never really understood the point of this semi-sequential >>>> paradigm. If you >>>> have other work to do then do it in another thread, thats the whole >>>> point of >>>> threading! >>> >>> This already works with multiple threads, no problem. But, if a >>> thread fails to acquire the mutex, it can check to see if it has any >>> other work to do instead of just waiting in the kernel doing nothing, >>> or spinning doing nothing... Make sense to you? >>> >>> >>>> Meanwhile if a thread needs to wait for a lock then just let it wait. >>>> >>> >>> The idea is instead of letting it wait, why not let it try to do some >>> other work? Think of an adaptive mutex. On contention it will spin >>> for a bounded number of times in user space before having to wait in >>> the kernel. Well, instead of spinning, try to do something else, some >>> real work? It will keep the thread hot, doing work instead of just >>> waiting... >>> >>> >> Maybe in old single processor systems it could be useful to avoid >> spinning and make the processor available for other work. >> Nowadays each system has many processors and if one of them spins for >> a brief period, that is not a problem. The work that can be done when >> one thread is spinning, can be done in other threads. >> So, the need for such a complicated solution might be present only in >> very exceptional cases. > > Say the mutex is not all that "critical" to grab. Also, the backoff > limit is there to make sure that the mutex shall be acquired. Also, a > lot of this other work can be thread local, so another thread cannot > start working on it? When the mutex is acquired a thread can do some > interesting things. Check global state, check for update commands, to > update the server, ect... But, the point is that when the mutex is not > able to be locked, the thread will at least try to do something else? Is > this okay, or just pie in the sky crap? As I said, i can see some very exceptional cases where this may be needed. But in the general case it is too vague, because 'something else' is not well defined. In the general case I would prefer a redesign, where the 'something else' is done in another thread.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-06 15:36 -0700 |
| Message-ID | <1070leb$3lg2n$2@dont-email.me> |
| In reply to | #122472 |
On 8/6/2025 1:56 AM, Fred. Zwarts wrote: > Op 06.aug.2025 om 01:07 schreef Chris M. Thomasson: >> On 8/5/2025 1:27 AM, Fred. Zwarts wrote: >>> Op 04.aug.2025 om 21:34 schreef Chris M. Thomasson: >>>> On 8/4/2025 1:48 AM, Muttley@DastardlyHQ.org wrote: >>>>> On Sat, 2 Aug 2025 12:58:23 -0700 >>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wibbled: >>>>>> On 7/29/2025 10:54 PM, Chris M. Thomasson wrote: >>>>>>> This is using the idea of trying to do other work while a mutex is >>>>>>> contended. Why spin or wait when we don't really have to? The >>>>>>> per- thread >>>>>>> random numbers in this experiment are only there to try to >>>>>>> simulate when >>>>>>> a contended thread has any other work to do. This can be check per- >>>>>>> thread stacks, queues, ect... Here is my example code. Can you >>>>>>> get it to >>>>>>> run, and can you show me the output? Now, this can work in real >>>>>>> world >>>>>>> environments. It's a stare to an adaptive mutex that just spins >>>>>>> doing >>>>>>> nothing... lol... ;^) >>>>>>> >>>>>>> I compiled it using c++20 >>>>>>> >>>>>>> (read all...) >>>>>> [snip code] >>>>>>> Any luck? Its fun to see how many work items were completed when the >>>>>>> mutex was contended... >>>>>> >>>>>> I guess the main point is that if a try_lock() fails, then we can >>>>>> _try_ >>>>>> to do "other" work... That can be checking thread local queues, >>>>>> stacks, >>>>> >>>>> I never really understood the point of this semi-sequential >>>>> paradigm. If you >>>>> have other work to do then do it in another thread, thats the whole >>>>> point of >>>>> threading! >>>> >>>> This already works with multiple threads, no problem. But, if a >>>> thread fails to acquire the mutex, it can check to see if it has any >>>> other work to do instead of just waiting in the kernel doing >>>> nothing, or spinning doing nothing... Make sense to you? >>>> >>>> >>>>> Meanwhile if a thread needs to wait for a lock then just let it wait. >>>>> >>>> >>>> The idea is instead of letting it wait, why not let it try to do >>>> some other work? Think of an adaptive mutex. On contention it will >>>> spin for a bounded number of times in user space before having to >>>> wait in the kernel. Well, instead of spinning, try to do something >>>> else, some real work? It will keep the thread hot, doing work >>>> instead of just waiting... >>>> >>>> >>> Maybe in old single processor systems it could be useful to avoid >>> spinning and make the processor available for other work. >>> Nowadays each system has many processors and if one of them spins for >>> a brief period, that is not a problem. The work that can be done when >>> one thread is spinning, can be done in other threads. >>> So, the need for such a complicated solution might be present only in >>> very exceptional cases. >> >> Say the mutex is not all that "critical" to grab. Also, the backoff >> limit is there to make sure that the mutex shall be acquired. Also, a >> lot of this other work can be thread local, so another thread cannot >> start working on it? When the mutex is acquired a thread can do some >> interesting things. Check global state, check for update commands, to >> update the server, ect... But, the point is that when the mutex is not >> able to be locked, the thread will at least try to do something else? >> Is this okay, or just pie in the sky crap? > > > As I said, i can see some very exceptional cases where this may be needed. > But in the general case it is too vague, because 'something else' is not > well defined. In the general case I would prefer a redesign, where the > 'something else' is done in another thread. Fair enough. But, well, if "something else" can be done in the same thread, well, why not try it, if the mutex is locked in the mean time? Grasping at straws here? Humm... It's a very specialized back off. I think it can be more "productive" than your run of the mill adaptive mutex, in a sense. Instead of spin, try something else...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-04 12:38 -0700 |
| Message-ID | <106r28d$2bkpn$4@dont-email.me> |
| In reply to | #122456 |
On 8/4/2025 1:48 AM, Muttley@DastardlyHQ.org wrote:
> On Sat, 2 Aug 2025 12:58:23 -0700
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wibbled:
>> On 7/29/2025 10:54 PM, Chris M. Thomasson wrote:
>>> This is using the idea of trying to do other work while a mutex is
>>> contended. Why spin or wait when we don't really have to? The per-thread
>>> random numbers in this experiment are only there to try to simulate when
>>> a contended thread has any other work to do. This can be check per-
>>> thread stacks, queues, ect... Here is my example code. Can you get it to
>>> run, and can you show me the output? Now, this can work in real world
>>> environments. It's a stare to an adaptive mutex that just spins doing
>>> nothing... lol... ;^)
>>>
>>> I compiled it using c++20
>>>
>>> (read all...)
>> [snip code]
>>> Any luck? Its fun to see how many work items were completed when the
>>> mutex was contended...
>>
>> I guess the main point is that if a try_lock() fails, then we can _try_
>> to do "other" work... That can be checking thread local queues, stacks,
>
> I never really understood the point of this semi-sequential paradigm. If you
> have other work to do then do it in another thread, thats the whole point of
> threading! Meanwhile if a thread needs to wait for a lock then just let it wait.
>
Lol. I asked an AI about it. Well, it seemed to "like" it and spit out
some code:
AI generated:
__________________________________
#include <iostream>
#include <random>
#include <thread>
#include <atomic>
#include <mutex>
#include <queue>
#include <chrono>
#define CT_WORKERS (103)
#define CT_ITERS (6996699)
#define CT_BACKOFFS (42)
#define CT_RAND_MAX (1000 )
#define CT_RAND_THRESHOLD (969)
struct io_packet {
int id;
char payload[64];
};
thread_local std::queue<io_packet> local_io_queue;
io_packet generate_io_packet(int id) {
io_packet pkt;
pkt.id = id;
for (int i = 0; i < 64; i++) {
pkt.payload[i] = (char)((id + i) % 256);
}
return pkt;
}
struct ct_shared {
std::mutex m_fun_mutex;
std::atomic<unsigned long> m_other_work{ 0 };
std::atomic<unsigned long> m_io_work{ 0 };
int m_test_count0 = 0;
bool sanity_check_validate() const {
return (m_test_count0 == CT_ITERS * CT_WORKERS);
}
};
void do_other_work(ct_shared & shared) {
for (volatile int k = 0; k < 50; ++k) {}
shared.m_other_work.fetch_add(1, std::memory_order_relaxed);
if (!local_io_queue.empty()) {
local_io_queue.pop();
shared.m_io_work.fetch_add(1, std::memory_order_relaxed);
}
else {
local_io_queue.push(generate_io_packet(rand()));
}
}
void worker_productive(ct_shared & shared) {
std::random_device rnd_seed;
std::mt19937 rnd_gen(rnd_seed());
std::uniform_int_distribution<unsigned long> rnd_dist(0, CT_RAND_MAX);
for (unsigned long i = 0; i < CT_ITERS; ++i) {
unsigned long backoff = 0;
while (!shared.m_fun_mutex.try_lock()) {
unsigned long rnd0 = rnd_dist(rnd_gen);
if (rnd0 > CT_RAND_THRESHOLD || backoff > CT_BACKOFFS) {
shared.m_fun_mutex.lock();
break;
}
do_other_work(shared);
++backoff;
}
shared.m_test_count0 += 1;
shared.m_fun_mutex.unlock();
}
}
void worker_baseline(ct_shared & shared) {
for (unsigned long i = 0; i < CT_ITERS; ++i) {
shared.m_fun_mutex.lock();
shared.m_test_count0 += 1;
shared.m_fun_mutex.unlock();
}
}
int main() {
using clock = std::chrono::high_resolution_clock;
ct_shared shared_prod;
auto start_prod = clock::now();
{
std::thread workers[CT_WORKERS];
for (int i = 0; i < CT_WORKERS; i++)
workers[i] = std::thread(worker_productive,
std::ref(shared_prod));
for (int i = 0; i < CT_WORKERS; i++)
workers[i].join();
}
auto end_prod = clock::now();
if (!shared_prod.sanity_check_validate()) {
std::cout << "Error: sanity check failed for productive version\n";
return 1;
}
auto prod_time_ms =
std::chrono::duration_cast<std::chrono::milliseconds>(end_prod -
start_prod).count();
std::cout << "Productive mutex:\n";
std::cout << " Elapsed time: " << prod_time_ms << " ms\n";
std::cout << " CPU-bound other work: " <<
shared_prod.m_other_work.load() << "\n";
std::cout << " IO completions processed: " <<
shared_prod.m_io_work.load() << "\n";
std::cout << " Total useful work (main + other + IO): "
<< (shared_prod.m_other_work.load() +
shared_prod.m_io_work.load() + (CT_WORKERS * CT_ITERS)) << "\n\n";
ct_shared shared_base;
auto start_base = clock::now();
{
std::thread workers[CT_WORKERS];
for (int i = 0; i < CT_WORKERS; i++)
workers[i] = std::thread(worker_baseline,
std::ref(shared_base));
for (int i = 0; i < CT_WORKERS; i++)
workers[i].join();
}
auto end_base = clock::now();
if (!shared_base.sanity_check_validate()) {
std::cout << "Error: sanity check failed for baseline version\n";
return 1;
}
auto base_time_ms =
std::chrono::duration_cast<std::chrono::milliseconds>(end_base -
start_base).count();
std::cout << "Baseline mutex:\n";
std::cout << " Elapsed time: " << base_time_ms << " ms\n";
std::cout << " CPU-bound other work: " <<
shared_base.m_other_work.load() << "\n";
std::cout << " IO completions processed: " <<
shared_base.m_io_work.load() << "\n";
std::cout << " Total useful work (main + other + IO): "
<< (shared_base.m_other_work.load() +
shared_base.m_io_work.load() + (CT_WORKERS * CT_ITERS)) << "\n\n";
double throughput_gain = 100.0 *
((shared_prod.m_other_work.load() +
shared_prod.m_io_work.load() + (CT_WORKERS * CT_ITERS))
- (shared_base.m_other_work.load() +
shared_base.m_io_work.load() + (CT_WORKERS * CT_ITERS)))
/ (double)(CT_WORKERS * CT_ITERS);
std::cout << "Total useful throughput gain vs baseline: " <<
throughput_gain << "%\n";
return 0;
}
__________________________________
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-08-05 07:29 +0000 |
| Message-ID | <106sbse$2kd9g$1@dont-email.me> |
| In reply to | #122458 |
On Mon, 4 Aug 2025 12:38:52 -0700 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wibbled: >Lol. I asked an AI about it. Well, it seemed to "like" it and spit out >some code: > >AI generated: I'm not even going to attempt to figure out wtf is going on there. Looks like it ripped off code from some project on github wholesale.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-05 16:08 -0700 |
| Message-ID | <106u2ua$31pq8$3@dont-email.me> |
| In reply to | #122461 |
On 8/5/2025 12:29 AM, Muttley@DastardlyHQ.org wrote: > On Mon, 4 Aug 2025 12:38:52 -0700 > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wibbled: >> Lol. I asked an AI about it. Well, it seemed to "like" it and spit out >> some code: >> >> AI generated: > > I'm not even going to attempt to figure out wtf is going on there. Looks > like it ripped off code from some project on github wholesale. > > Afaict, it seems to be trying to show how much other work can be done when a try_lock fails, vs just waiting on the mutex spinning and/or waiting in the kernel?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-06 15:51 +0200 |
| Message-ID | <106vmkt$3dbbe$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122453 |
Am 30.07.2025 um 07:54 schrieb Chris M. Thomasson: > This is using the idea of trying to do other work while a mutex is > contended. ... This situation almost never happens. It requires that the locking can be delayed an arbitrary time. You feel like a genius with that and you've invented nonsense.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-06 15:34 -0700 |
| Message-ID | <1070laa$3lg2n$1@dont-email.me> |
| In reply to | #122475 |
On 8/6/2025 6:51 AM, Bonita Montero wrote: > Am 30.07.2025 um 07:54 schrieb Chris M. Thomasson: > >> This is using the idea of trying to do other work while a mutex is >> contended. ... > > This situation almost never happens. > It requires that the locking can be delayed an arbitrary time. Not an arbitrary time. Its bounded. > You feel like a genius with that and you've invented nonsense. > Huh? Don't project on me. I was asking a question.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-07 06:44 +0200 |
| Message-ID | <1071av4$3pk10$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122477 |
Am 07.08.2025 um 00:34 schrieb Chris M. Thomasson: > On 8/6/2025 6:51 AM, Bonita Montero wrote: >> This situation almost never happens. >> It requires that the locking can be delayed an arbitrary time. > Not an arbitrary time. Its bounded. No one actually follows this silly idea.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-08-07 12:17 -0700 |
| Message-ID | <1072u4m$6rav$1@dont-email.me> |
| In reply to | #122481 |
On 8/6/2025 9:44 PM, Bonita Montero wrote: > Am 07.08.2025 um 00:34 schrieb Chris M. Thomasson: > >> On 8/6/2025 6:51 AM, Bonita Montero wrote: > >>> This situation almost never happens. >>> It requires that the locking can be delayed an arbitrary time. > >> Not an arbitrary time. Its bounded. > > No one actually follows this silly idea. > I don't think its totally silly. Why spin in an adaptive mutex backoff when other work be done? It's akin to a backoff with meaning, not just doing nothing.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-08-07 21:51 +0200 |
| Message-ID | <107303h$7iei$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122486 |
Am 07.08.2025 um 21:17 schrieb Chris M. Thomasson: > On 8/6/2025 9:44 PM, Bonita Montero wrote: >> No one actually follows this silly idea. > I don't think its totally silly. ... It is.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web