alegr1,
Certainly true, but for thread synchronization it was very valuable. Even if they do not solve all sorts of problems, that shouldn't be a reason for reject in cases where they might have an essential effect.
These instructions could still be valuable as building blocks for making a distributed sync mechanism. But once you go into distributed synchronization requiring message exchanges, you raise the minimal cost by a few orders of magnitude anyway.
Could any mechanism based on atomic operations (i.e. various variants of turning off the interrupt system) by themselves serve in a distributed system? This also includes the case when the kernel (or whatever handles the sync mechanism) runs at a higher hardware priority level: While it prevents local processes from interfering with the semaphore update, it will not be communicated to other CPUs.
As long as the processors have physically common RAM, the CPU and memory controller could offer some uncached and memory locked read&set or increment instruction, where one CPU may ask the memory controller to delay accesses from other CPUs until the composite access is completed. That wouldn't help you if the CPUs don't have common memory. SOLO might also set similar flags to the memory controller. (In fact, you could have up to four ND-500 CPUs working on the same RAM, but I never checked out the effect of the SOLO instruction - I never worked on a multi-CPU system in those days.)
