In what sense does each thread appears to the operating system as a separate CPU?

2
votes

In the book Modern Operating Systems,

Multithreading has implications for the operating system because each thread appears to the operating system as a separate CPU. E.g., Consider a system with two actual CPUs, each with two threads. The operating system will see this as four CPUs.

I don't understand that. A thread is a light weighted process which in turn is a running program. A cpu is a hardware.

A thread runs on a cpu.

An OS manages the hardware directly including cpu, while processes (including threads) see the hardware indirectly via the abstraction provided by OS. How can an OS not know how many cpus are there?

In what sense does each thread appears to the operating system as a separate CPU?

Thanks.

3
multithreadingoperating-system
The statement is silly, IMHO. It's the operating system that defines the concept of a thread, so how can it see one as something other than what it itself defined? – 500 - Internal Server Error
Just a wild guess - it would seem to me that by "thread", they're referring to hyperthreading here, not e.g. pthreads OS-level threads. Related terms would be simultaneous multi-threading (SMT) - a single physical CPU core presenting multiple sets of CPU context resources to the OS to appear as multiple "virtual CPUs"... Unless that fact is disambiguated elsewhere, I would concur that it's a bit poorly written... – twalberg

3 Answers

1
votes

The fact that a cpu have multiple physical cores, is one thing (cpu cores), but the fact that the cpu can have virtual cores, are usually called "threads" in the hardware context(but they are not the same as the programming term "threds"). The simple way to think about "threads" in a hardware context is the amount of cpu cores (notice however this is partially correct, and incorrect as well, but in order to understand the difference I would recommend looking at wikipedia, for example: https://en.wikipedia.org/wiki/Hyper-threading).

1
votes

The statement is not "silly" and is a decent first approximation to understanding tasking and threading.

A task/thread has a set of registers, a memory address space (populated with RAM and sometimes ROM), and the ability to execute instructions. This is the same as a basic CPU. So one can conceive of a multi-tasking or multi-threading system as being a collection of CPUs.

(And, to carry this analogy further, there are situations where multiple threads/tasks are simulated on a single thread/task.)

Yes, modern CPUs have a lot of extra registers and controls for, eg, controlling tasks and threads, but that's going beyond the basics.

And, from the standpoint of multi-threading within an OS, it is true that there are essentially the same concerns about synchronization and atomicity whether you have multiple streams of execution running in multiple threads on a single CPU, or the multiple streams each running on its own CPU. The only major difference is with regard to cache coherence, and even for that case there exist systems where each thread on a single CPU has its own cache.

1
votes

The various threads of a SMT CPU appear as separate cores to the OS. For example on x86 with hyperthreading, interprocessor interrupts apply to virtual cores. For example a SIPI (start-up ipi) addressed to "all" will fire up all threads, not just all actual physical cores.

The OS can know how many APs (application processors, contracted with the BSP, bootstrap processor, which is the one that starts when you turn the machine on) there are by observing how many times the code that you instructed them to start at (with the SIPI) runs (but this is better used a check), or by parsing the MP tables (definitely do that, you have to anyway in order to detect memory layout and devices and so on).