Memory part 6: More things programmers can do

I think there is an inherent semantical difference between LL/SC and CAS. In the first case
the store fails when another CPU has written to the memory location, no matter what the value
is. Even if the other CPU writes the exactly same value that was there before, SC will fail.
Not so with CAS, that fails only if the other CPU has written a different value.

From a CPU designer point of view those are really different operations:

LL/SC needs to remember the address loaded with LL, and set a flag once another CPU requests
ownership of that address (to write), so that SC can fail.

CAS needs to actually lock the memory location for the duration of the read-compare-store. As
it's atomic, I assume that on start of the opcode the CPU requests ownership for the
variable's address, then reads the value to compare it. What happens if during this time
interval another CPU requests ownership of that address? The opcode is atomic, so the other
CPU must wait as long as the compare and store operation is going on? I.e. the bus operation
is stalled for that amount of time, reducing memory bandwidth? Or how does it work?

For that reason I have always thought that LL/SC was the more efficient algorithm, as it does
not lock the bus, thus not forcing other CPUs to wait.

It probably depends on the amount of collisions (two CPUs competing for the same variable at
the same time) one expects. Low collision numbers allow for LL/SC to have a low number of
loops due to failing SCs, while high collisions would lead to an increasing number of loops in
LL/SC so that CAS would be more efficient.