CODEWITHSUNDEEP
operating-systemmutexschedulermulticore
Kaputnik120
Kaputnik120

Reputation: 300

How do Operating Systems schedule multiple threads on multiple CPU cores simultaneously?

I'm currently reading Tanenbaum's Modern Operating Systems and have a question about Gang- or Co-Scheduling:

It's stated that an Operating Systems code is divided into logical parts by Mutexes to allow different parts of the OS to be executed simultaneously on different CPU cores (e.g. the file system code can be run in parallel with the code handling interrupts). This means that the part of the OS which is responsible for the thread or process scheduling must be protected by a mutex.

Additionally it's stated that if two processes A and B are communicating heavily, the OS should use Gang- or Co-Scheduling to let these two processes be run on different cores at the same time. This is a performance improvement because both processes might otherwise be blocked by waiting for the answer of the respective other process.

Now my questions:

  1. How does an OS schedule a process or thread on a core on which it's not currently running? E.g. the scheduler runs on core X and therefore can only switch the context to another thread on core X and not CPU/core Y.

  2. How is the OS able to schedule multiple cores at a time? If the scheduler only runs on one core and is protected by a mutex to not run on multiple cores at a time?

Upvotes: 3

Views: 2203

Answers (1)

bazza
bazza

Reputation: 8414

On a symmetric multi processor architecture all CPUs have equal access to all memory. A thread's object code and data is accessible to all cores and processors, so it is easy to "move" a thread / process from core to core. The kernel simply needs to implement a scheduling scheme to ensure that everything that needs to run gets run as best as possible. A thread / process that was interrupted on one core can be resumed on another with very little penalty.

Exactly what that scheduling scheme is varies. There could be a single scheduler task running on a single core that controls what's running on all the other cores. Alternatively there could be a mini-scheduler per core that looks after scheduling on just that core, co-operating with its peers to spread threads around. This is, I think (corrections welcome), what Linux does.

Upvotes: 2

Related Questions