-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SpinLocks suffer from false sharing #55942
Comments
Yes, and many other issues. Don't use them |
I disagree about |
We have a plan to remove them from the language. Their only use should be in places where we can't reschedule stuff i.e the compiler or the scheduler itself. |
What's wrong with a SpinLock? For sufficiently narrow locks, (e.g. to implement atomics etc), I thought they were relatively close to optimal. |
Since Suppose Suppose that the two threads aren't even waiting on the two locks, but just acquire them:
and Thread B:
Here the two threads don't contend at all, logically, but the lock instructions will run slowly because the cache line must bounce back and forth. This kind of contention is an example of false sharing. |
In my experience, sometimes you need a spin lock. Is there some where I can read about the plan to remove SpinLock? |
@gbaraldi after our discussion on friday I'm still not clear on this. Can you reply to Oscar's and Bradley's questions here? |
There isn't a plan to remove it. It's just that spin locks in general are quite bad as locks. They are only good when uncontended and held for a very small amount of time |
SpinLocks can suffer from false sharing.
The text was updated successfully, but these errors were encountered: