I'm curious about this "composability" advantage. In lecture, Kunle said that transactional memory is more composable than using a locking mechanism, but I'm having trouble understanding what this means in practice.

Would that have something to do with exceptions? In previous lectures, there were examples where if a program locks something and throws an error, it requires extra care by the programmer to undo the lock.

+1 for composability. What is there besides the fact that TM takes care of nesting much better?

W.r.t performance portability, does the limitation (locking scheme for 4 CPUs may not be the same as 64 CPUs) apply on both software and hardware TM?

I think composability indeed refers to what @joshcho describes as nesting, but I'd say that's a substantial property in a large program and/or libraries. You can just write each functionality of your program, using the TM abstractions at any appropriate granularity, and if some of your transactions call other functions/modules that might also invoke TM, it's both safe (e.g., no deadlocks) and scalable (e.g., no redundant unlock/lock behavior or contention).

If I'm understanding this correctly, this "composability" and built-in safety will not necessarily result in the most efficient implementation of a system (runtime-wise), correct?

@thepurplecow I am inclined to agree because the built-in safety checks will definitely incur some overhead which will result in leaving some performance on the table. But probably worth it.