Idea for new VDSO feature: a function to query whether there are tasks waiting to run on the current cpu.
If there are tasks waiting, spinning for a mutex is wasting cpu time during which something else could be running.
-
-
yielding while spinning? I think that's not a good idea.
-
No. Immediately using futex_wait instead of spinning for a while first.
-
Spinning first is almost-pure-win (modulo slight electricity cost) if nothing else is waiting to run, pure-loss if something is.
-
not pure loss. Scheduling decides if it's a loss. What's the compelling argument for messing with scheduling?
-
I think you're misunderstanding. Every spin for which you don't get the lock is wasted cpu cycles. Scheduler is irrelevant.
-
If there was nothing else that wanted to use those cycles, no big deal. But if there was, you've incurred a cost.
-
Re: "messing with scheduling", spinning at all is messing with scheduling. The default, polite action would be to always futex_wait.
-
Spinning is "I don't have anything to do yet, but let's trick the scheduler so it doesn't let someone else have my cpu time".
- 1 more reply
New conversation -
-
-
how big is the win if there are waiting tasks? Spin for < 50 is small cost.
-
The idea is that you can afford to spin longer if you know you're not preventing other tasks from running.
-
right, we were talking about something similar for JavaScript SAB and C++ synchronic: expose "how many spins".
End of conversation
New conversation -
-
-
for some uses, I have a "try to lock or fail immediately" mutex, so a thread can "do whatever" when the resource is available.
-
That's a trylock op, not a lock op, and not related to the topic at hand since it never involves waits or spins.
-
yeah, but can be cheap. otherwise, typically just do a short spin and then yield (ex: 256 cycles), since this generally works ok
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.