Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #122474
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: fun with a mutex... |
| Date | 2025-08-06 12:04 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <106vgd1$5pk$1@reader1.panix.com> (permalink) |
| References | <106cc2f$31ti3$1@dont-email.me> <106u31a$31k65$2@dont-email.me> <106u86u$t1c$1@reader1.panix.com> <106udu9$3400b$2@dont-email.me> |
In article <106udu9$3400b$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 8/5/2025 5:38 PM, Dan Cross wrote: >> In article <106u31a$31k65$2@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 8/5/2025 12:27 AM, Muttley@DastardlyHQ.org wrote: >>>> On Mon, 4 Aug 2025 12:34:08 -0700 >>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wibbled: >>>>> [snip] >>>>> 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? >> >> The idea behind what you're trying to do is well-understood. >> >> In fact, this is what generally happens when you try to acquire >> a contended, blocking mutex: if the mutex is currently locked by >> some other thread, you mark the acquiring thread as blocked >> waiting on the mutex, and then yield control back to a scheduler >> or something; eventually the other thread will finish what it >> was doing and release the mutex, but part of releasing the mutex >> and making it available again is marking threads that were >> blocked on it runnable, thus opening them up to be scheduled >> again, where they can once again try to acquire the mutex. >> >> The twist here seems to be that, instead of immediately >> yielding, for some bounded number of times, you look at a work >> queue and try to find something else for the acquiring thread to >> do while the lock you want is unavailable. Regardless, the >> effect is more or less the same. >> >> Personally, I see little benefit, and a number of potential >> pitfalls. In particular, I see no reason why the bundled bits >> of work in this scheme can't cause any number of lock ordering >> violations and lead to all sorts of deadlock scenarios. Suppose >> for example, that I acquire some mutex, A, and then go to >> acquire a second mutex, B: B is currently held by some other >> thread, so I begin to spin, but I see that there is an item in >> my work queue, so I go to do that. The first thing that work >> item does is try to acquire mutex A, which I'm currently >> holding, leading to deadlock against A. >> >> One could perhaps assert that these work items are not allowed >> to take or hold locks, which could address this particular >> failure mode, but it's unclear how one might enforce this in >> general, and there may well be other, similar failure modes. >> >>>>> [snip] >>>>> 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... >>>> >>>> Because while its doing something else the lock maybe become free then >>>> become acquired again leading to a kind of race condition of some threads >>> >>> Nope. A thread can only do something else for a bounded number of times. >>> So, its starvation free. No race condition. >> >> This is simply not true. Suppose that the "something else" is >> computationally intensive, or blocks the thread somehow (say, by >> executing a blocking system call). What if the "something else" >> just spins in an infinte loop, waiting for some event? Just >> because you bound the number of times you do "something else" >> does not mean you are free of starvation, because what the other >> thing actual does matters. > >Using this pattern, well, can be a nightmare, but can be somewhat >beneficial at the same time? Yeah, so beneficial that it's been codified many times over: acquiring a contended blocking mutex yields, so that something else can run instead. >If a programmer knew that a class of >functions are compatible with the try_lock failed condition, well, why >not give them a go? Better than spinning doing nothing, or god forbid, >waiting in the kernel? The whole premise of a spinlock is that the critical section that it protects is short (like, a few instructions), so the overhead of spinning is smaller than the overhead of context switching to something else. If that is not true, you shouldn't be using a spinlock as your mutex primitive in the first place, and a blocking or adaptive mutex is more appropriate. By the way, there's nothing at all wrong with blocking in the kernel; given a reasonable OS, it's not like if *YOUR THREAD* isn't running the CPU will be idle or something. But if you still want to avoid blocking when a mutex is unavailable, then you've got the idea inverted. Focusing on the locking protocol as some kind of generic place to do "other work" is too general to be useful, as has been shown. To be truly useful, this sort of approach must be coupled with knowledge of what a thread can safely do in context, which means that you really need to specialize the behavior for the _critical section_, not the _mutex_: the programmer knows why the thread is trying to acquire a mutex in that case, and what other work may or may not be acceptable to do if the mutex isn't immediately available. So they can craft the critical section to take advantage of that knowledge themselves. This sort of technique is well-known, by the way. But then it's not going to be particularly general. And you may argue that the critical section might be buried deep down in a call stack, very far away from the place where the programmer can reasonably make a decision about whether it's safe to do something or not, so that's a more appropriate place: but that reinforces the objections: if the critical section is so far away from the point where the programmer knows whether it's safe for the thread to do something else, then the programmer doesn't really know whether that thing is safe, because the intervening calls might have changed conditions so that it's not, so trying to plumb that knowledge down to the mutex code is again too dangerous to be useful. But even if the programmer could safely interpose doing "something else" in this way, they may not have full knowledge to know whether or not that will cause the thread to block. Consider, for example, a program that tries to do something innocuous, like zero a a few byte's worth of memory while trying to take a lock; what if the page holding the memory to be zero'ed has been stolen by the OS in the meantime, and now the program (totally unbeknownst to it) incurs a page fault that requires reading data from secondary storage to resolve? Not only has a single store now blocked your thread in the big scary kernel, but it's blocked it for many, many cycles. So while this technique is known and used in existing systems, it must be done so carefully that it really isn't appropriate as a general mechanism. - Dan C.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web