I think Kayvon had a great way of explaining one key advantage of transactions over locks in lecture. He said that locks always prevent concurrency through mutual exclusion, but oftentimes this is not optimal for performance because sometimes the two things being locked can actually happen concurrently without requiring synchronization; transactions attempt to solve this problem.

To build on what @felixw17 said, transactional memory makes it so that the execution of your program will exhibit as much parallelism as is present in the actual access patterns, not in the locking design! This is done by eliminating the need for mutual exclusion for read-read "conflicts" which are not really conflicts at all.

One downside the transactional memory is the potential for starvation of longer transactions by shorter transactions and the need to do a lot of extra work that processors will need to throw away at the end.

I'm curious to know how much overhead there is for transactional memory. There are probably cases where using something like a read-write lock outperforms TM since it allows for concurrent reads.

The productivity argument here reminds me of our subsequent discussion of DSLs and Halide, in that by hiding the implementation details from the programmer and only allowing a few declarative control knobs, this allows the programmer to be more productive while maintaining most of the performance benefits of fine grained locks.