Can the threads spawned by a process run on different cores of a multicore system?
Let's say I have a process P from which I have spawned two threads t1 and t2 and it's a multicore system with two cores C1 and C2. My questions are:
Can the threads spawned from a process run on different cores of a multicore system?
Yes. Assuming that the hardware has multiple cores, and provided that the operating system supports / permits this. (Modern operating systems do support it. Whether it is permitted typically depends on the admin policy.)
Will the threads t1 and t2 run in the same memory space as process P?
Yes. They will use the same memory / virtual address space.
Can a thread t1 execute in a different core than which process P is running on? For example, process P is running on the core C1 and thread t1 is running in core C2?
This question does not make sense.
A POSIX process doesn't have the ability to execute code. It is the processes threads that execute code. So the idea of a "process running on core C1" is nonsensical.
Remember: every (live) POSIX process has at least one thread. The process starts with one thread, and that thread may spawn others if it needs to. The actual allocation of threads to cores is done by the operating system and will vary over the life time of the process.
This is how threads work in modern operating systems. For Linux, the current (POSIX compliant) way of implementing threads was introduced with Linux 2.6 in 2003. Prior to the Linux 2.6 kernel, Linux did not have true native threads. Instead it had a facility called LinuxThreads:
"LinuxThreads had a number of problems, mainly owing to the implementation, which used the
clonesystem call to create a new process sharing the parent's address space. For example, threads had distinct process identifiers, causing problems for signal handling; LinuxThreads used the signals SIGUSR1 and SIGUSR2 for inter-thread coordination, meaning these signals could not be used by programs."
(From Wikipedia.)
In the (pre 2003!) LinuxThreads model, a "thread" was actually a process, and a process could share its address space with other processes.
Generally this depends on how threads are implemented in the OS scheduler.
That said, all modern OSes I know of will explicitly try to dispense threads in a way, that a good balance between cost of context switches and good parallelity is achieved. This implies, that if there is at least one idle core and no power capping / power napping / power preserving mode is active the waiting thread will be scheduled to the idle core.
If harsh power management is in place, the scheduler might chose to wait a tick or two before waking up that idle core - if the already running core frees up it can save a lot of juice.
