Previous | Next --- Slide 28 of 31
Back to Lecture Thumbnails

What are some possibilities that cause a "well written code with locks" to be faster than lock-free code?

One thing I can think of from this lecture is that we are using atomic operations like "compare_and_swap" in lock-free data structures to avoid the overheads of using locks, which are expensive (but I guess what matters here is how expensive they are compare to the overheads of using locks). It is also mentioned in next slide that a lock-free design does not eliminate the contention problem.


If you have very high contention, you might spend a very large amount of time spinning around the compare-and-swap operation, which could incur huge delays. On the other hand, many mutex implementations provide a property called bounded waiting (once you call mutex_lock, there will be a bounded number of other threads that get the lock before you do). Simply looping around compare-and-swap doesn't provide this guarantee, so in cases with high contention a mutex might be preferable.


@Olorin Interesting information.


As my understanding, in most cases, programming with locks is more convenient than programming with lock free data structure. Designing a good lock free data structure is difficult. That's why lock is more popular than free data structure.