Spinlock vs std::mutex::try_lock

Question

What are the benefits of using a specifically designed spinlock (e.g. http://anki3d.org/spinlock) vs. code like this:

std::mutex m;
while (!m.try_lock()) {}
# do work
m.unlock();

Why not just m.lock();? What's the point of the busy wait? — Igor Tandetnik
In this case, I have many idle cores and want to minimizing the latency in which each thread starts work. Felt like a spinlock was what I needed, but I didn't understand why using a mutex for this wasn't common and I kept seeing different homegrown implementations of spinlocks instead. — user2411693
I suspect that try_lock() is about as expensive as lock(), and you are getting the worst of both worlds - the cost of a trip to the kernel, and using your CPU as a space heater. — Igor Tandetnik
So the benefit of a hand-rolled spinlock is that it's guaranteed to spin in userspace? And if try_lock require a system call, then I'll be losing context and paying the latency anyways? — user2411693
@user2411693 If you're going to assume your platform's spinlock implementation is so bad that even the most naive implementation is better, you should assume that about other things your platform provides too and just abandon the platform. — David Schwartz

David Schwartz David Schwartz · Accepted Answer · 2016-02-11T06:00:23

On typical hardware, there are massive benefits:

Your naive "fake spinlock" may saturate internal CPU buses while the CPU spins, starving other physical cores including the physical core that holds the lock.
If the CPU supports hyper-threading or something similar, your naive "fake spinlock" may consume excessive execution resources on the physical core, starving another thread sharing that physical core.
Your naive "fake spinlock" probably does extraneous write operations that result in bad cache behavior. When you perform a read-modify-write operation on an x86/x86_64 CPU (like the compare/exchange that try_lock probably does), it always writes even if the value isn't changed. This write causes the cache line to be invalidated on other cores, requiring them to re-share it when another core accesses that line. This is awful if threads on other cores contend for the same lock at the same time.
Your naive "fake spinlock" interacts badly with branch prediction. When you finally do get the lock, you take the mother of all mispredicted branches right at the point where you are locking out other threads and need to execute as quickly as possible. This is like a runner being all pumped up and ready to run at the starting line but then when he hears the starting pistol, he stops to catch his breath.

Basically, that code does everything wrong that it is possible for a spinlock to do wrong. Absolutely nothing is done efficiently. Writing good synchronization primitives requires deep hardware expertise.

Spinlock vs std::mutex::try_lock

2 Answers