iirc, Kunle mentioned in chat box that test-and-set will always write (hence why BusRdX is always issued, regardless of whether or not the lock was acquired). So, if I'm interpreting correctly, even if the value of mem[addr] is already 1, test and set will still write a 1 to mem[addr]? Why not just do the behavior described in the comment on slide 17 of only setting mem[addr] when mem[addr] is 0?

Or if my interpretation is wrong, why is it that BusRdX is issued on every t&s?

@ufxela I think test-and-set is an atomic operation, and it will potentially do a write, so we always treat it as a write operation and issue the BusRdX. When mem[addr] is 1, it may be both fine to write or not write 1 to that addr.

This is another great example of the abstraction vs. implementation theme of this course. There are many possible ways to implement the lock abstraction, but each of these implementations has different advantages and disadvantages, and in order to understand the tradeoffs, you have to examine the implementations of the abstractions that the lock implementation relies on (in this case, the abstraction being used is cache coherence).

This slide shows a drawback of our preliminary test-and-set implementation of a lock, since it requires constant BusRdX messages to be sent every time a processor attempts to acquire the lock, which generates a lot of coherence traffic.