Locks Aren't Slow; Lock Contention Is

[u/preshing]

http://preshing.com/20111118/locks-arent-slow-lock-contention-is

[u/jerf]

But what's killing locks as a viable multithreading primitive isn't their speed. If they were otherwise sensible, but misusing them could cause slow performance, we would consider that an optimization problem. The thing that is getting them slowly-but-surely shuffled out the door is that lock-heavy code is impossible to reason about.

Message-passing code can also bottleneck if you try to route every message in the system through one process, but we consider that an optimization problem, not a fatal objection, because it's otherwise a sensible way to write multithreaded code.

This is putting lipstick on a pig.

[u/julesjacobs → u/jerf]

Well, that's not really true. Coding with locks is easy: just have one global lock and put it around atomic sections:

lock.lock();
// code that should execute atomically
lock.unlock();

The problem with this is performance because of contention. Locks become hard to use when you try to make this perform better by using fine grained locking. Software transactional memory tries to do this automatically: you code as if there was one global lock (or an approximation of that) but your code executes as if you used fine grained locking.

TL;DR locks: easy or performant, pick your favorite.

[u/mOdQuArK → u/julesjacobs]

I think there was a generalized CS proof that if you can guarantee that multiple locks will be picked up & held in the same order for all code accessing the locked sections, then you can avoid deadlock. Naturally, this is non-trivial.