Atomicity is a guarantee of isolation from concurrent processes.
Consider that we have two threads T1 and T2 both wanting to update a shared variable x (say x += 5 and x += 10) respectively. If initially x = 5, we'd expect x = 20 after both instructions execute. However, without a guarantee of atomicity, a possible sequence of operations is:
T1: load 5 from x
T2: load 5 from x
T1: set x to 5 + 5 = 10
T2: set x to 5 + 10 = 15
Now at the end x = 15 instead of 20 as desired. If these operations were atomic, we'd guarantee that we'd have x = 20 at the end. We can implement this idea using the ideas mentions on the slide - locks, control blocks, or instrinsic operations. In the last case, atomicAdd(x,10) would guarantee that you would load the value of x, add 10, and then set the value without any other instructions from other concurrent processes interleaved that could cause problems like I mentioned above.
yimmyz
In short, atomic execution sequence should only lead to one of the following two results:
- No effect is done;
- The entire sequence finishes.
Namely, there should never be cases where a portion of the execution sequence completes, leaving side effects, yet it does not finish entirely. A good example is shown above.
ZhuansunXt
Now having finished assignment 3, GCC's sync_compare_and_swap is a kind of hardware-supported read-modify-write operation to guarantee atomicity.
What does atomicity mean in this context?
Atomicity is a guarantee of isolation from concurrent processes.
Consider that we have two threads T1 and T2 both wanting to update a shared variable x (say x += 5 and x += 10) respectively. If initially x = 5, we'd expect x = 20 after both instructions execute. However, without a guarantee of atomicity, a possible sequence of operations is:
T1: load 5 from x
T2: load 5 from x
T1: set x to 5 + 5 = 10
T2: set x to 5 + 10 = 15
Now at the end x = 15 instead of 20 as desired. If these operations were atomic, we'd guarantee that we'd have x = 20 at the end. We can implement this idea using the ideas mentions on the slide - locks, control blocks, or instrinsic operations. In the last case, atomicAdd(x,10) would guarantee that you would load the value of x, add 10, and then set the value without any other instructions from other concurrent processes interleaved that could cause problems like I mentioned above.
In short, atomic execution sequence should only lead to one of the following two results: - No effect is done; - The entire sequence finishes.
Namely, there should never be cases where a portion of the execution sequence completes, leaving side effects, yet it does not finish entirely. A good example is shown above.
Now having finished assignment 3, GCC's
sync_compare_and_swapis a kind of hardware-supported read-modify-write operation to guarantee atomicity.