People think optimistic STMs are faster than locks, because "locks are slow", but optimistic and pessimistic approaches are roughly equivalent when latency is l

People think optimistic STMs are faster than locks, because "locks are slow", but optimistic and pessimistic approaches are roughly equivalent when latency is low. Under low contention, both locks have low overhead, just like optimistic STMs. Under high contention, locks have high overhead, and so do optimistic STMs (due to wasted work). Pessimistic STMs are built on locks. They make code involving fine-grained locking composable. So you can have many more locks instead of a global one, and recover gracefully from read/write conflicts and deadlocks. When latency is high, e.g. in distributed systems, optimistic strategies are more efficient. When latency is low, e.g. in SMP memory, pessimistic strategies more efficient. So pessimistic lock-based STMs are generally more efficient. This implies that STM is not really a faster alternative to locking. It's a simply form of fine-grained locking that composes well. I believe STM will not eliminate the slowdown that results from fine-grained locking in freely-threaded Python interpreters, but it might just make them easier to write, which isn't a bad thing.