Yesterday we explored the prospects of multi-threading for HP 3000 sites. It's an aspect of application and software design that can benefit from virtualization. In years past, when much of the 3000 application base was being created, separate hardware CPUs drove this multi-threading. Stan Sieler of Allegro, one of the authors of the textbook on Precision Architecture RISC "Beyond RISC," told us that multi-threading is likely to have made its way into 3000 software via Unix.

It's a concept, through, that's been possible for MPE ever since its beginning. The MP in MPE stands for Multiprogramming, Sieler reminded me, and that "Multi-threading is a form of multiprogramming or multiprocessing."

Generally, but not always (as words are often abused), “threads” are related to a single process.  E.g., my video compression program might work on several parts of the video simultaneously with three or four threads. On some computers, two separate threads of a single process cannot execute at the same time … on others, they can.  

On most computers nowadays, threads are implemented at the operating system level. On older systems, threading was sometimes implemented above the operating system, relying on user code to switch threads.  (I’ll skip co-routines, which few systems have now, but the Burroughs MCP did.)

Multi-programming is the concept where two (or more) processes (or “programs”) appear to run at the same time, but in reality each gets a short time to run, and then the CPU pays attention to the other process, then back to the first one… or “time slicing.”

On the 3000, few programs use multi-threading, but it is available. It came about the same time as Posix did, perhaps one release later (I can’t recall). In general, if you show me a 3000 program that uses threading, I’ll bet it’s written in C and originated in the Unix/Linux world. 

Essentially all computers nowdays have multi-programming. The original HP 3000 (pre-CX) did, too. (The HP 2100 (running RTE) had, IIRC, no multi-programming.)