When CPU 1 issues a test-and-set instruction, the DPRAM first makes an "internal note" of this by storing the address of the memory location in a special place.
If at this point, CPU 2 happens to issue a test-and-set instruction for the same memory location, the DPRAM first checks its "internal note", recognizes the situation, and issues a BUSY interrupt, which tells CPU 2 that it must wait and retry.
If the test succeeds, the DPRAM sets the memory location to the value given by CPU 1.
If the test succeeds, the DPRAM sets memory location A to the value specified by CPU 1.
If the test fails, the DPRAM copies the value back from the special register to memory location A.
From that viewpoint, this can, correctly, be called "test-and-set" in the full, conventional sense of that term.
The essential point to note is the general intent and principle of test-and-set: a value is both tested and set in one atomic operation such that no other program thread or process can change the target memory location after it is tested but before it is set.
In the C programming language, the implementation would be like: The code also shows that there are really two operations: an atomic read-modify-write and a test.
Once the code writes the initial value, the result of the test has been established, even if it has not been computed yet — e.g., by the == operator.)
In absence of volatile, the compiler and/or the CPU(s) may optimize access to lock and/or use cached values, thus rendering the above code erroneous.
Conversely, and unfortunately, the presence of volatile does not guarantee that reads and writes are committed to memory.
The four major evaluation metrics for locks in general are uncontended lock-acquisition latency, bus traffic, fairness, and storage.
It slows down the overall section, since the traffic is saturated by failed lock acquisition attempts.
Test-and-test-and-set is an improvement over TSL since it does not initiate lock acquisition requests continuously.