As far as I understood reading a lot of information about threads, nowadays, if you have a unicore processor, all your programs are fragmented in different threads in order to be able to execute them concurrently.
If you have, for example, 3 cores and you run only one application, when I look information about this program execution I get something like: Thread 1: has done this Thread 2: this Thread 2: this Thread 3: this Thread 1: this Thread 3: this Thread 1: this ...
Are all threads of the same number related? Or they are completely independent parts of the application?
Thank you very much.
As far as I understood reading a lot of information about threads, nowadays, if you have a unicore processor, all your programs are fragmented in different threads in order to be able to execute them concurrently.
A program only performs work with multiple threads if it was explicitly designed to do so (or if it uses a higher-level mechanism to schedule concurrent workloads, in which case the thread scheduling is still present, but abstracted away). This is true regardless of whether you have one or many CPUs/cores available.
Each CPU can run one "thread" at a time, so if you have multiple CPUs/cores, then you can run multiple threads in parallel. When you have more threads than CPUs, they will have to take turns executing. The order of execution is determined by a scheduler, but typically a thread will run for some short period of time called a quantum. It may voluntarily yield the rest of its quantum at any time, or it may continue running until the scheduler decides it's time for another thread to run. If you have only one CPU, only one thread will execute at any given time--they're not truly running concurrently; rather, they are being interwoven in way that creates the illusion of concurrency.
If you have, for example, 3 cores and you run only one application, when I look information about this program execution I get something like: Thread 1: has done this Thread 2: this Thread 2: this Thread 3: this Thread 1: this Thread 3: this Thread 1: this ...
In literature about threading, you can generally assume that thread identifiers refer to unique threads. In practice, things aren't as clear-cut, and you can't assume much about those IDs.
One of the important things to keep in mind about threads is that they are largely conceptual. Threading libraries are often just a scheduling abstraction implemented on top of another scheduling layer. If you are using a threading library that gives each thread a unique numerical ID, you can generally assume that ID will always refer to the same conceptual thread within that library for the current process, at least up until the thread terminates. Outside of the current process, that ID may be meaningless, and even within the process, if a thread terminates, another thread may be created later using the same ID.
A given programming language/runtime may expose its own threading API, but the threads it provides may not have a one-to-one mapping to the kernel-level threads managed by the OS. A thread provided by a threading library may end up executing on one or more different kernel threads throughout its lifetime, and while its thread ID may remain constant, it may have no relationship to the ID of the kernel thread(s) to which it is bound. Within your process, this doesn't really matter. But if you talk to other processes, or interact with OS-level APIs that reference threads, you need to be aware of this mismatch. The same goes if you use different threading libraries in the same application.