@haboric, it happens when Processor 1 release the lock, which means updating the shared variable and invalidate the cache line of other processors.
@Khryl My understanding of the "Invalidate line" in the last row for Processor 1 is caused by BusRdX from Processor 2.
Test-and-test-and-set lock still cause contention when the lock is released.
My understanding here is this:
Proc1 did a BusRdX and acquired the lock, set it to 1. Now, latest dirty cache line is in Proc1. When Proc2 and Proc3 try to acquire lock, they do a while(lock != 0);, so each of them just reads the line, for which Proc1 doesn't have to invalidate its cache line. So the dirty cache line stays in Proc1 and now Proc2 and Proc3 have the cache line in shared state too. Now, Proc1 needs to release the lock, so it needs exclusive access to the cache line, and hence it sends a BusRdX. Proc1 updates the cache line and sets lock = 0. Thereafter, Proc2 wants to acquire the lock (it wins the arbitration for BusRdX in the "if(test_and_set(*lock) = ...)" part. So Proc2 sends a BusRdX, causing P1 to invalidate the cache line. Now Proc2 has cache line in exclusive state and sets lock to 1.