Malte Skarupke (malteskarupke.delete@this.web.de) on January 4, 2020 11:22 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on January 3, 2020 6:05 pm wrote:
> > So now you still hold the lock, but you got scheduled away from the CPU, because you had
> > used up your time slice. The "current time" you read is basically now stale, and has nothing
> > to do with the (future) time when you are actually going to release the lock.
>
> Right so this is a hard thing to measure,

Actually, it isn't. It might be hard to measure in a _portable_ manner, but take a look at ebpf on linux, and just instrument the relevant scheduler calls. Bonus points you could even monitor scheduler effectiveness in preventing cache ping-pong by running on same core.

The TL;DR I've found is that it is unlikely you can beat futexes in "real world" usage, because busy-spinning [in userspace] really just isn't good use of CPU cycles, and is an anti-pattern of just using up larger amounts of your timeslice before the scheduler schedules you away.
Is your benchmark really representing what your game engine does? If so, seems very suboptimal to have so many threads racing in the manner described.

You seem to also be talking about two very different things: you want low latency AND you want fairness. There was a LPC talk you might be interested in, you may want to explore some of hte options listed there:
https://linuxplumbersconf.org/event/4/contributions/286/attachments/225/398/LPC-2019-OptSpin-Locks.pdf