The atomic keyword can be implemented by lock, but using lock is able to achieve flexible behavior than atomicity.

I'd also argue that the atomic keyword allows for flexible behavior as well (despite the programmer not having to think about the flexible behavior), since as we saw later in the lecture, atomic can be implemented in ways that ensure atomicity while still potentially allowing for parallelism.

This is another instance of the abstraction vs. implementation theme that we've been seeing throughout the course. The declarative construct "atomic" is the "abstraction" that will implement synchronization as necessary, but under the hood it could use locks or something else. This is similar to how using ISPC foreach "declares" that the loop can be parallelized, but it's up to the system to choose how it wants to do so.

Transactional memory models are more relevant in multicore systems and concurrent/parallel computing environments. Using locks in these scenarios become too challenging and burdensome for programmers to enforce atomicity efficiently.

The point above alerts me to the fact that transactional memory is useless /not applicable when it comes to a single-threaded application. Does this mean that hardware with built-in TM constructs incurs unnecessary overhead when running a single-threaded application? Or are hardware TM constructs capable of making themselves effectively disappear without much effect on performance when they are not needed? Is there a way for the programmer to say "I'm gonna run this on a single thread, so I don't want the hardware to do any of the bookkeeping work needed for TM"?