Previous | Next --- Slide 35 of 60
Back to Lecture Thumbnails
matteosantamaria

I think the difference between atomics and locks can be thought of as the typical "abstraction vs. implementation" difference. The atomic is more of an abstraction -- it declares that some operations must be performed atomically, but makes no guarantees about how atomicity is enforced. Locks, on the other hand, are much more lower level and can be used to implement the atomic keyword (as explained by the slide).

gohan2021

I found the second point to be inspiring: not all usage of locks can be represented with atomic regions. As an example, I think it would be difficult to use atomic transaction to implement hand over hand locks for linked list. In some sense, their difference is that locks provide flexibility in a program for ensuring the mutual exclusive access, whereas atomic ensures the transactional properties of software modules.

shaan0924

The third point is very interesting to me. Naturally having an erroneous split between atomic regions in a function will lead to atomicity violations, but are there instances in which there are no "mistakes" on the programmer's part that still lead to atomicity violations? Off the top of my head I think there may be some situations in which two threads are trying to write to each other atomically that could cause issues but are there any others that maybe locks would resolve better?

jkuro

@gohan2021 thats a really good observation of bringing up the hand-over-hand locking and how that does not transfer over to atomic regions. really helped me understand this slide better

apappu

Also really appreciated Gohan's point on this slide! locks seem like they can, in some instanes, provide the programmer with more granular control of what thread interleaving behavior is allowed

jennaruzekowicz

I think adding to what is above, it is extremely interesting how there can be various ways to implement atomicity. Especially in the case where there can actually be instructions between instructions that are surrounded by atomic calls, so long as they do not modify or read similar data. I have much interest in further investigating how compilers implement these processes in the most efficient ways. Does anyone know of classes that may go over/teach this?

terribilis

Locks in the lower level function as a strong control over a threads ability to run. When a thread is waiting on a lock, the thread is removed from the scheduler and only moved back when it acquires the lock. This is something that atomics don't implement.

alishah

is there a good example of where atomic regions can't replace locks?

gsamp

@alishah Slide 36 shows an example in which locks work but atomic doesn't.

Please log in to leave a comment.