New to the world of parallel computation. Would it be correct to say that CPU's are actually thread calculators? My understanding currently: a process is composed of multiple threads and a single core on a cpu is capable of executing instructions from 1 thread at a time, sometimes a bit more when taking into account hyper-threading, but essentially it is computing threads. When the CPU, along with all of its cores, are done calculating all of the threads that belong to a specific process then that process would be considered complete.

So like an analogy would be:

A CPU is like a monkey, with N number of mouths (cores). Each mouth is responsable for eating a long chain of bananas (threads) out of wooden crates (processes). We can increase the rate at which some program is finished/emptied, by hooking up more banana chains from it to an empty and waiting core/mouth. A program is called complete if the wooden crate is emptied of all bananas.

Would this interpretation be correct?

Below is an illustration of my current understanding enter image description here

also what are some of the practical differences (programming-wise) of what I can/cannot do with spawning new processes vs threads. I always see something along the lines of processes have their own memory while threads share it but what do they really mean by that? Like in python, can I just go like from thread_a import var_something?

  • 1
    $\begingroup$ Welcome to CS.SE! We prefer that you ask one question per post. (Also, "What are some of the differences.." is probably too broad to be a good fit here.) You might want to edit your question accordingly. $\endgroup$
    – D.W.
    Feb 15 '16 at 7:03

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.

  • $\begingroup$ I would like to learn more about the subtle nuances of threads/processes and the more detailed mechanisms in how they share resources. Where could I go to learn this? Would this be in the domain of an introductory to OS course, or parallel programming? Any recommended materials? $\endgroup$
    – AlanSTACK
    Feb 15 '16 at 19:56
  • $\begingroup$ Any modern decent introduction to operating systems will cover this. Probably the best it Andrew Tanenbaum's book "Modern Operating Systems". There are also some excellent lecture series on the net, such as this one: youtube.com/playlist?list=PLC22A3C78768EF026 $\endgroup$
    – Pseudonym
    Feb 16 '16 at 0:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.