3 ms·
> It's software; it can always be fixed. ;) No, it cannot be fixed, because the kernel simply does not have enough information in the case of naive spin locks
by quotemstr 7y ago
> It's software; it can always be fixed. ;)
No, it cannot be fixed, because the kernel simply does not have enough information in the case of naive spin locks to make good scheduling decisions. I understand the Chesterton's-fence argument in favor of learning why game developers use spin locks before telling them to do something else, but in this case, I really think simple ignorance is the most likely explanation.
You never want a spinlock in userspace. Period. An adaptive mutex will give you what you want without the pathological downsides.
Look: your whole line of reasoning here is just bizarre and invalid. You can't say "well, maybe there's a reason they're doing it!" without actually backing this claim up with specific reasoning. Sorry, but you can't keep using your spinlocks even if they "work" on other platforms. If they "work" there, it's an accident.
- shadowgovt 7y ago> You never want a spinlock in userspace What if you've already used them in code that runs in N other architectures, the game works fine in those architectures, and Linux is architecture N+1, which you're trying to decide to support or not? The less the code has to be changed, the easier it is to support architecture N+1.
- jcranmer 7y ago> No, it cannot be fixed If it cannot be fixed, then why is it only a problem for Linux?
- gpderetta 7y agoIt can obviously be "fixed", but the problem is that it might regress other loads that have been tuned for the current behaviour.
- bryanlarsen 7y agoI imagine it's a problem on all operating systems trying to run multiple games or other heavy+responsive workloads simultaneously.