So just to clarify, the race condition comes into play because it requires loading and storing from memory which has very high latency, and this increased latency makes it so that we can't assume sequential consistency for a lock if another processor were to do the same? It's not atomic because we cannot always assume sequential instruction execution if more than one context were to execute lock/unlock because there can be some indeterminate latency for load or store?
EggyLv999
The latency isn't the only issue. Let's say that somehow both threads end up on the same processor; then after thread 0 loads, the processor context switches to thread 1, runs 1 command, and switches back. So the non-sequential execution can be caused by other mechanisms besides unfortunate latency problems (although that's definitely possible)!
carnegieigenrac
@amolakn Data races are possible even without taking into account latency or the reordering of instructions. In the example from the slide, 2 different processors look at the lock at the same time. Since one processor isn't aware that the other is looking at the lock, they both assume that they can lock it themselves if it's already unlocked. At this point both processors may end up executing the critical code at the same time.
So just to clarify, the race condition comes into play because it requires loading and storing from memory which has very high latency, and this increased latency makes it so that we can't assume sequential consistency for a lock if another processor were to do the same? It's not atomic because we cannot always assume sequential instruction execution if more than one context were to execute lock/unlock because there can be some indeterminate latency for load or store?
The latency isn't the only issue. Let's say that somehow both threads end up on the same processor; then after thread 0 loads, the processor context switches to thread 1, runs 1 command, and switches back. So the non-sequential execution can be caused by other mechanisms besides unfortunate latency problems (although that's definitely possible)!
@amolakn Data races are possible even without taking into account latency or the reordering of instructions. In the example from the slide, 2 different processors look at the lock at the same time. Since one processor isn't aware that the other is looking at the lock, they both assume that they can lock it themselves if it's already unlocked. At this point both processors may end up executing the critical code at the same time.