`  ::::May I please see a citation for your assertion that ASMP and SMP are terms of art rather than terms that have something to do with symmetry?  If a system where all processors are equivalent in hardware, and where the operating system doesn't assign special roles to any of the processors, I fail to see any lack of symmetry between the processors, so it's not ``asymmetric`` in the dictionary sense.  ::::As for a ``progression``, that implies a one-dimensional scale.  Whether a system that has something that could be considered ``processes`` supports multiple processes per user session, or supports multiple preemptively-scheduled threads of control per process, is orthogonal to the form of multiprocessing.  A uniprocessor system, or a multiprocessor system with only one processor running kernel code, or a system where any processor can run kernel code but there's a giant lock around the kernel, can support multiple processes per user session (and many have), and can even usefully support multiple preemptrively-scheduled threads of control per process.  The fact that Multics didn't support multiple processes per user session, or multiple preemptively-scheduled threads of control per process, has nothing to do with whether it can make full use of multiple processors; it was a multi-user system, and multiple processes could be making ring 0 calls at the same time.  The reference states  :::::Multics system programmers working on the supervisor, on the other hand, worked in an environment in which many kinds of data were shared and had to be protected by locking and access conventions. Ring 0 of a Multics process contained multiple shared databases that needed protection. These protections and access conventions were created as a layer of usage convention on top of the execution environment provided by the hardware and PL/I language.  ::::which at least suggests that Multics had something finer-grained than a giant lock around ring 0, and indicates that there was no designated ``ring 0 CPU``.   `