SpinLocks suffer from false sharing

[kuszmaul]

SpinLocks can suffer from false sharing.

[vtjnash]

Yes, and many other issues. Don't use them

[kuszmaul]

I disagree about kind:invalid. SpinLocks are there. There are cases where they solve a problem that the other locks cannot solve. It would be easy to provide an option that doesn't suffer from false sharing. (I have a proposed patch that I'll share).

[gbaraldi]

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.

[oscardssmith]

What's wrong with a SpinLock? For sufficiently narrow locks, (e.g. to implement atomics etc), I thought they were relatively close to optimal.

[kuszmaul]

Since SpinLock is just 8 bytes long, you can end up with two or more of them on the same cache line.

Suppose lk1 and lk2 are both on the same cache line and you have two threads waiting on the two locks respectively. Then the cache line will bounce back and forth between the caches of the two threads. That cache traffic can use up memory bandwidth.

Suppose that the two threads aren't even waiting on the two locks, but just acquire them:
Thread A:

@lock lk1 foo1()
bar1()
@lock lk1 zot1()

and Thread B:

@lock lk2 foo2()
bar2()
@lock lk2 zot2()

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.

[kuszmaul]

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.

In my experience, sometimes you need a spin lock. Is there some where I can read about the plan to remove SpinLock?