•
u/xiao_sa 2h ago
Remind me of this article:
https://www.siliceum.com/en/blog/post/spinning-around/
One of the best reading found in this subreddit.
•
•
Remind me of this article:
https://www.siliceum.com/en/blog/post/spinning-around/
One of the best reading found in this subreddit.
•
•
u/ReDucTor Game Developer | quiz.cpp-perf.com 38m ago
Even when you have threads pinned to dedicated cores, you would need to ensure that your not ending up with more then one thread pinned to another core. And if your in user mode in any environment that you do not completely control your at the whim of being preempted by another thread in a different process, leaving your spinning thread now just spinning away wasting its allocated time slice.
If you plan on making any library which is public, do not fill it with spin locks because you won't be able to control the places which people use it, and randomly throwing in an OS yield is not going to solve issues just make them worse.
Depending on the CPU you can also do umwait/mwaitx which can be better then doing a pause loop, but unfortunately it's not consistent between CPU vendors.
Use adaptive mutexes (most mutex implementations already are), these will do a little bit of spinning before putting the thread to sleep if it was unable to acquire the lock.
Also if your optimizing your locks for high contention, it's probably a sign to look more at your higher level design, because your still fighting the CPUs cache coherance which will kill your performance anyway.