Is it correct to say that CPUs only compute threads?

Question

As a newcomer to the field of parallel computation, is it accurate to say that CPUs are essentially "thread" calculators? My current understanding is that a "process" is made up of multiple "threads" and a single core of a CPU can execute instructions from one "thread" at a time, sometimes a bit more with hyper-threading, but essentially it is computing threads. Once the CPU, along with all of its cores, have finished calculating all the "threads" that belong to a specific "process," then that "process" would be considered complete.

So like an analogy of this concept would be:

A CPU can be likened to a monkey, with N number of mouths (cores). Each mouth is responsible for eating a long chain of bananas (threads) out of wooden crates (processes). By connecting more banana chains from a program to an empty and waiting core/mouth, we can increase the rate at which the program is completed/emptied. A program is deemed complete once the wooden crate is emptied of all bananas.

Would the following interpretation be correct?

Answer 1

Take a step back. In most operating systems, a process is an entity that owns resources, like memory areas, open files, and such. A thread is an entity that can be scheduled (i.e., get a CPU core assigned, has its own contents of registers and local variables). Several threads can exist within the same process, sharing it's resources.

Switching between threads that share memory means that the table pages and cache entries don't have to be flushed, and that is a major cost in current processors (today to access a word in memory can take the same time than hundreds of instructions!).

Note that some systems (like Linux) have a non-standard view of threads, in that you can create a new thread from an existing one and specify in detail exactly what they are to share.

Is using threads or processes a win? No way to answer in full generality. If different threads of execution don't use the same data, it won't matter much (see above), and it can be advantageous for them not to be able to trample on each other's work. Use processes. If they share data intimately, threads are a better match (and will be more efficient). But then again, having several cores accessing the same data gives rise to cache ping-pong and bad performance. Also, taking such a program and rewrite to run on a distributed system (note that current massive machines are NUMA, essentially separate machines connected by an insanely fast network, but still much slower than direct access to memory) will be much harder.