The TS instruction checks if a particular address in memory contains the value zero, if so it writes the value 1 to the memory address, if not, it leaves the value as is. However, in these slides, we see that at every TS instruction, we issue a BusRdX, meaning that we always intend to write/modify the contents of the lock, even if the compare part of the TS instruction fails. Something that is not written in this slide, but really helped me wrap my head around this is that we the TS instruction actually writes every time it is executed, even if the compare portion fails. If the compare passes, then it writes a 1, but if it fails, it rewrites the current value in memory. I hope this helps clarify any confusion.

This is not the ideal behavior of a lock, since it creates a ton of memory traffic. Hm... if only there was a way where we didn't have to continuously change our memory state to an exclusive one.

The first processor who tests and sets locks the lock - the corresponding cache line goes to M state. When another processor tries to test and set the lock, the first processor issues BusWB and the new processor issues BusRdX. So the new processor gets M state but the first processor gets invalidate state. As it is locked now, the new processor will not be able to secure the lock. So it keeps spinning and issuing back to back BusWB and BusRdX transactions which makes the interconnect traffic heavy. This continues till processor 1 unlocks by issuing BusRdX(because it now is in I state) and BusWB to write the value in the memory as 0. Next time when a new processor runs ts, it issues BusRdx. It will now be successful in securing the lock. Same story repeats.

But one important thing to notice here is that - while the lock is locked, due to the new processors trying to secure the lock continuously, interconnect traffic shoots up slowing down the critical section in the first processor - which delays the unlocking further.

That's why with more processors, the time to secure a lock becomes higher and higher