Why no double wide compare and swap on Sparc 4387

the traditional locking on 360 multiprocessors had been test-and-set.

charlie was doing a lot of multiprocessor fine-grain locking work for cp-67 at the science center

when he invented compare-and-swap (came up with compare-and-swap to match charlie's initials "CAS").

a large part of the invention of compare-and-swap was because he noted that much of the fine-grain test&test locking was purely for some simple storage updates ... aka pointers and counters ... and that compare-and-swap could accomplish both the "locking" of the earlier test-and-set ... but the compare-and-swap semantics could also be used to directly accomplish various storage updates w-o having to acquire independent locking operations.

early attempts to deal with the pok 370 architecture group trying to get compare-and-swap into 370 architecture wasn't succesful. they claimed that the "mainstream" (pok) operating system group didn't see sufficient additional smp benefit of compare-and-swap over the earlier simple test-and-set for locking. they said that in order to get compare-and-swap justified for 370 architecture a non-smp lock use had to be used.

as a result, the multi-threaded application use for various storage location updates was invented (independent of running on a single processor or a multiprocessor). in the traditional smp kernel use, the instruction stream is disabled for interrupts so a lock, load, modify, sotre, unlock sequence ... so there isn't a lot of deadlock problems. in multi-thread applications, the lock, update, unlock sequence could be interrupted with another thread getting dispatched and then deadlocking (which then requires all sorts of logic to avoid). the atomic compare-and-swap operation significantly reduced the various deadlock scenarios and software complexity for dealing with them.

the original rios-power-rs6000 didn't have for shared-memory multiprocessing as well as no compare-and-swap instruction. the problem was that in the intervening years (between early 70s and early 90s) a number of multi-threaded applications (like large database infrastructures) had adopted use of compare-and-swap instruction. in order to simplify support, aix defined a software compare-and-swap macro ... which interrupted into the kernel and had a special fast-path for emulating compare-and-swap semantics (while disabled for interrupts, aka approx. atomic compare-and-swap in a single processor environment).

misc. past posts on smp, compare-and-swap, etc