Here when threads are trying to acquire lock, they do not call the test-and-set instruction repeatedly that generates a lot of BusRdx and invalidating each other's cache line (even when another thread is currently holding the lock). Instead, they repeatedly try to read the lock variable (the cache line will be S state in all of the processors, and don't need to be invalidated). Only when the lock is released (flag set to 0 & written back to memory), the threads will run test-and-set and try to acquire the lock.

Here when processor 2 acquires the lock and later when processor 3 attempts to update the lock, shouldn't cache line in proc 2 go to shared state and not invalidate?

I was wondering why that is the case too. I think maybe this might be a case where proc 3 still reaches the t&s update attempt right after proc 1 releases the lock and a little bit after proc 2 successfully acquires the lock first. This might still generate a change to M state. Proc 3 just didn't get there first.